1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<!--Converted with LaTeX2HTML 98.1 release (February 19th, 1998)
originally by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Evangelism: A Unix Bigot and Linux Advocate's Spewings</TITLE>
<META NAME="description" CONTENT="Evangelism: A Unix Bigot and Linux Advocate's Spewings">
<META NAME="keywords" CONTENT="lj_advocacy">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
ALINK="#FF0000">
<!--endcut ============================================================-->
<H4>
"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <HR> <P>
<!--===================================================================-->
<H1 ALIGN="CENTER">Evangelism: A Unix Bigot and Linux Advocate's Spewings</H1>
<P ALIGN="CENTER"><STRONG>By <A HREF="mailto:davew@cloudnet.com">David A.
Wagle</A></STRONG></P>
<P ALIGN="LEFT"></P><HR> <P>
<BR>
<H2><A NAME="SECTION00010000000000000000">
Table of Contents</A>
</H2>
<!--Table of Contents-->
<UL>
<LI><A NAME="tex2html2"
HREF="./wagle.html#SECTION00020000000000000000">Introduction: What's the Point?</A>
<LI><A NAME="tex2html3"
HREF="./wagle.html#SECTION00030000000000000000">A Conversion Story?</A>
<LI><A NAME="tex2html4"
HREF="./wagle.html#SECTION00040000000000000000">Why Linux Didn't Work</A>
<UL>
<LI><A NAME="tex2html5"
HREF="./wagle.html#SECTION00041000000000000000">What Learning Curve?</A>
</UL>
<LI><A NAME="tex2html6"
HREF="./wagle.html#SECTION00050000000000000000">The Problem and Three Solutions:</A>
<UL>
<LI><A NAME="tex2html7"
HREF="./wagle.html#SECTION00051000000000000000">Big Blue, Round Two</A>
<LI><A NAME="tex2html8"
HREF="./wagle.html#SECTION00052000000000000000">OK, Take A Deep Breath!</A>
<LI><A NAME="tex2html9"
HREF="./wagle.html#SECTION00053000000000000000">Putting one foot in front of the other</A>
</UL>
<LI><A NAME="tex2html10"
HREF="wagle.html#SECTION00060000000000000000">Why it isn't happening?</A>
<LI><A NAME="tex2html11"
HREF="wagle.html#SECTION00070000000000000000">Conclusion</A>
</UL>
<!--End of Table of Contents-->
<P>
<H1><A NAME="SECTION00020000000000000000">
Introduction: What's the Point?</A>
</H1>
<P>
Linux users are a notorious bunch. We tend to be vociferous OS
bigots of the first order. This is a trait that has served
the software community well. After all, if we were not that
way we would never have put the time and effort into
developing, deploying, and supporting the thing. But it also
a trait that has drawbacks. Some of these drawbacks are
serious, and effect our ability to present Linux as a serious
alternative to other, more prominent OS's (using the term, in
many cases, very loosely).
<P>
I'm not going to try to present the Linux alternative in
anything but a fair and honest way. That means I'm not going
to be talking about the possibility of loosing your job for
choosing Linux -- after all, that is not a problem that is
unique or limited to any one OS. The fact is that when you
choose the wrong tool for mission critical applications, you
should be called to task for that choice. This is regardless
of the OS's involved. Likewise I will not clamor on that
Linux is the one, true solution to all problems. Such a
statement, however much I'd like it to be so, is just as
foolish.
<P>
But, I wish to be clear that I will not have many good things
to say about those other OS's. For the most part they are
deserving of their poor reputations and of the scorn of any
true Linux afficionado. Still, there are better and worse
ways of promoting the <EM>Nearly</EM> One True OS that is Linux.
In this paper I would like to discuss some of those options.
<P>
<H1><A NAME="SECTION00030000000000000000">
A Conversion Story?</A>
</H1>
<P>
A few weeks ago I helped a friend (we'll call him Mike, being
that that is his name and I could care less about his
anonymity) install Red Hat 5.0 on his system. I made certain
that all the configuration files were properly tweaked for his
particular computer. I installed KDE, and made KDM the
default login method. I set up his networking, making sure
that it handled everything seamlessly in the background. Then
I showed him where the docs, howto's, mini-howto's and the
like were located. I spent time with him making sure he knew
how to use info, find, grep, ps, which, apropos and the man
pages. After a few hours of work and teaching, I went my
happy way convinced that another conversion to the Linux way
(tm) had taken place. After all, Mike hated Windows and had
had nothing but problems with both 95 and NT.
<P>
But the next week when I stopped over, I found my friend was
back to running Windows 95, unhappy as ever about his daily
crashes and computer problems. It is important to understand
that Mike isn't some <EM>luser</EM>; rather, he is a
sophisticated computer professional with substantial computer
knowledge. He has been a consulting parter with me for major
corporations, and has worked on developing a number of expert
systems. He knows his stuff very well. So why, then, did
Mike fail to embrace the Linux alternative?
<P>
<H1><A NAME="SECTION00040000000000000000">
Why Linux Didn't Work</A>
</H1>
<P>
The answer, unfortunately, is one we advocates hear all the
time. The new user of the Linux system finds that the
learning curve is too steep to be manageable. Like many other
people, Mike has a real life - he has a job, a girlfriend,
various projects and hobbies, and he can not spend all his free
time learning a new way of being productive. Moreover, he
can't afford to devote the days or even weeks it might take
him to learn how to administer a system so that he can
accomplish even simple tasks. He needs to be productive
today, and tomorrow, at the same rate he was yesterday.
Because Mike is already familiar with the system and
applications on the windows box, and not with those on Linux,
he could not afford to switch. When the initial learning curve
is so steep getting to be equally productive when moving from
another OS to Linux can be daunting. This is even more true
if one is an expert user on the non-Linux machine.
<P>
<H2><A NAME="SECTION00041000000000000000">
What Learning Curve?</A>
</H2>
<P>
Many <EM>OS Bigots</EM> (myself included on my more polemical days)
will counter that it is simply untrue that it takes that long
to learn a new system. Or we'll simply deny that Linux is
really all that complicated. Instead of recognizing any
validity in the statements made by the complainants, we
attempt to invalidate the complaint by suggesting that the
person in question must be a <EM>luser</EM> instead of a <EM>user</EM>.
``I learned Unix in a couple of hours,'' or ``Heck, just pick
up <U>Unix Unleashed</U> and read it,'' are statements that carry
the implication that the person being addressed is somehow not
as competent as the speaker.
<P>
This approach does more damage to the Linux (and Unix)
community than many people realize. We have good solutions to
many problems, but if we aren't willing to take the people who
need those solutions seriously, we will not be heard.
<P>
<H1><A NAME="SECTION00050000000000000000">
The Problem and Three Solutions:</A>
</H1>
<P>
So, the question arises, ``How do we Linux users, developers,
and advocates help those with limited time for learning new
systems make the switch?'' There are several answers to this
question, but they almost all fall into three categories. I
call these categories the <EM>OS/2 revisited approach</EM>, the
<EM>suck it up approach</EM>, and the <EM>delayed skill
transfer approach</EM>. What are these methods? Glad you asked!
<P>
<H2><A NAME="SECTION00051000000000000000">
Big Blue, Round Two</A>
</H2>
<P>
The first, the <EM>OS/2 revisited approach</EM>, consists of
making windows available on or under the new OS. IBM had
moderate success in getting dissatisfied users to switch to
their products by providing a technically superior system that
managed to provide the user with their favorite windows
applications. Linux has a number of programs and libraries
available that help with this approach. DOSEMU, the TWIN
library, WINE, WABI, and others are all efforts to provide the
user with access to his favorite MS products.
<P>
This approach has some big dividends. The user is able to
transfer many of his or her skills immediately. There is
little trepidation in wondering how to do word processing on
the very same word-processor you've been using for the last 2
years. There is far less worry about being able to get your
work done when you don't have to worry about finding and
learning new applications in order to accomplish your normal
tasks.
<P>
However, this approach does have some problems. Today, the
most obvious is that windows95 apps are not nearly as portable
to Linux emulation as are the older 3.x apps. This means that
many users are not able to bring over their favorite
applications any more. Rather, the user needs to find and
obtain an outdated version of his or her favorite product. The
user then will need to worry about reformatting old data and
projects to use the older program, as well as concerning
themselves with being able to share their data seamlessly with
coworkers.
<P>
Another major drawback with this approach, as IBM found out,
is that the users are not encouraged to explore the power of
the underlying OS. ``A better memory manager for windows'' is
not what Linux is about. It is not what it does best. And,
like OS/2, eventually users who use it for that purpose will
realize that the increased complexity doesn't pay out any real
dividends. The reason OS/2 failed (regardless of what the
various OS/2 pundits say, it is dead) is the same reason these
various projects will never really be the answer to Linux
advocacy. They don't really solve the problem of getting
users up on the new OS. All they do is offer a false sense of
security at a cost of complexity and a lack of compatibility
with state-of-the-art Windows environments (if there is such a
thing.)
<P>
The trend to develop Windows95-like applications such as
StarOffice on Unix platforms seems to be an extension of this
methodology. Instead of embracing the tenants of ``small is
beautiful'' and ``make each program do one thing well,'' these
development efforts are aimed at reproducing the Suite on Unix.
The advantage of this, is, of course, that it is what managers
expect to find on their computers. The disadvantage is that
the ``Office Suite,'' in all it's ugly, bloated, glory is now
nestled into the Unix culture. Most true devotee's of Unix
will likely dismiss these suites as being against the Unix
grain. Still, they present a way to move reluctant Windows95
people into the Unix world.
<P>
<H2><A NAME="SECTION00052000000000000000">
OK, Take A Deep Breath!</A>
</H2>
<P>
The <EM>suck it up approach</EM>, also known as the <EM>sink
or swim</EM> method can and does work. I, for example, simply
reformatted my hard-drive one day, and never looked back.
However, for most people in real-life business environments,
this isn't possible. Unlike most people, I really did have
lots of time to explore my system, and being in graduate
school, I had few applications I really needed to run.
``Mission Critical'' doesn't apply to most people in master's
programs. Like the example of Mike, above, the real user
just doesn't have the time to waste on learning how to be
productive all over again. Still, for some users, it can
work. The key is having good teachers who are also good
system administrators on hand to help the user along. Had I
been willing to visit Mike on a daily basis to hand hold
while he got up to speed, he would probably be running on Red
Hat instead of Redmond.
<P>
The advantage to this method is that it doesn't rely on a
sense of security. Unlike <EM>OS/2 revisited</EM>, the
<EM>suck it up'ers</EM> have to dive into the system, they have
to tackle the learning curve, and with good teachers it can
happen fairly quickly. Most people can learn the basics of
Emacs, LaTeX, Unix shells and command lines, and the various
other Unix tools and tricks in a week or less. While there
may still be some touch and go moments when problems with
system administration raise their ugly head, for the most
part, after some intensive training and a few moments of
butterflies in the stomach, the person can manage to get
along.
<P>
The problem with this approach is, of course, that it takes a
leap of faith, that most people are very leery of making.
And, I might add, they are right to be leery of doing it this
way. Some people simply won't get the new way no matter how
patient you are, because they will be stressing out over some
project that they are working on. Others, because of various
concerns about being able to get the job done, simply won't
leave the tried and true - no matter how obvious it is that
it is really tried and found wanting. Let's face it, most
people are nervous about the unknown, and moving to Linux is
the unknown for someone whose only computer experience is MS
or Mac based. Here again, the aforementioned Office-ish
suites can come in very handy. While rarely the best tool for
any one job, they can be used to make the <EM>suck it up'er</EM>
more comfortable in his or her new environment.
<P>
It is important to realize that there is always the
occasional person whose task still can not be adequately
completed under Linux. There are specialty apps which require
MS or Mac products to run. For these people, leaping before
looking, long and hard, can be disastrous. And, we gurus
need to be aware that one story from such a person on
newsgroups and mailing lists goes as far as ten stories of
positive experiences. Trying to coerce most people into the
<EM>suck it up</EM> method is just asking for trouble. You risk
your credibility about OS matters on your ability to teach and
support someone in learning a new environment. This is a
gamble that most likely won't pay off often enough to be worth
the risk. Our most powerful weapon in the Linux community has
always been our honesty and integrity when it comes to the
products we advocate. To push someone to use a system they
are not ready for can have deleterious effects on that
reputation.
<P>
<H2><A NAME="SECTION00053000000000000000">
Putting one foot in front of the other</A>
</H2>
<P>
This brings us to the last method - the <EM>delayed skill
transfer approach</EM>. What is this? It's simple -- give
Windows, NT and Mac users Unix tools to use on their current
projects! Simple, huh? The problem is, in our zest to push
the Linux point of view on people, we often forget that we can
give some demonstration of the power of the Unix way which is
utterly non-threatening to new users. By replacing the
command windows prompt with bash, by changing dir to ls,
by adding ghostview, ghostscript, emacs, perl, LaTeX and other
tools to the Windows environment, we allow for users to
develop their skills and confidence in Unix methods without
compromising their ability to currently work.
<P>
While this method may take longer to get any particular user
up and running in a completely Linux-only environment, it also
offers the most benefits with the fewest drawbacks. The
benefits of the <EM>OS/2 revisited</EM> method, namely that of
having tools that you are comfortable with, is realized
without the deficit of having to rely on out-dated versions
or be worried about underlying complexities. The drawbacks of
the <EM>suck it up</EM> approach are avoided as the users are
given plenty of time to become familiar with the new tools in
an environment that doesn't endanger any current projects.
Thus the users are less stressed and more open to trying new
things, for the new things don't entail the need to be
concerned about not being able to accomplish critical tasks.
<P>
Further, after a few weeks or months, those ``mission critical''
tasks are now being accomplished on Unix tools that have been
ported to the user's (soon to be formerly) favorite
platform. Thus, when the switch over to Linux comes, the user
no longer has to learn two new things - how to be productive
and how to system manage. Instead, they are instantly
productive and can learn the underlying system at their
leisure. More often than not they will come to want the extra
functionality of things like named pipes, IPC, and other Unix
niceties that are unavailable in their scaled down ports.
<P>
<H1><A NAME="SECTION00060000000000000000">
Why it isn't happening?</A>
</H1>
<P>
While this seems to be a fairly obvious method of helping
users move to Unix environments it seems to be one of the
least attempted. There are a few reasons for this.
<P>
<UL>
<LI>Advocates tend to be very strong in their opinion that
windows=bad, Unix=good. They are not particularly willing to
compromise their ideals for what seems like limited gains.
<LI>Advocates tend towards seeing the computing market as a
battleground of sorts where Unix is pitted against the ``evil
empire.'' Anything that doesn't seem like a direct attack upon
Microsoft can be seen as an act of near treason.
<LI>Linux users tend to spend lots of time under Linux,
they are a bit out of touch with the windows world. As a
result, they may not be aware of that neat new port of Bash as
the command shell under 95, or that perl can run (and do some
neat registry tricks too!)
</UL>
<P>
<H1><A NAME="SECTION00070000000000000000">
Conclusion</A>
</H1>
<P>
The point of all this is that there is more than one way to
skin a cat (or in the case of Gates-ware, a weasel). Linux
advocacy can, and should, take forms that are appropriate to
the particular situation of a particular user. A student in
a computer science program with lots of free-time probably
should opt for the <EM>suck it up</EM> approach. A person with
plenty of support from a local administrator and plenty of
legacy apps might benefit greatly from the <EM>OS/2
revisited method</EM>. And, most importantly, we can't forget that
promoting Unix tools under other OS's is a form of advocacy.
More importantly, in an environment where mission critical
apps and projects abound, it may be the most effective form of
advocacy. Keep up with available ports of your favorite Unix
tools under other systems, and you can increase your
conversion success rate!
<P>
<H1><A NAME="SECTION00080000000000000000">
About this document ... </A>
</H1>
<STRONG>Evangelism: A Unix Bigot and Linux Advocate's Spewings</STRONG><P>
This document was generated using the
<A HREF="http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 98.1 release (February 19th, 1998)
<P>
Copyright © 1993, 1994, 1995, 1996, 1997,
<A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
Computer Based Learning Unit, University of Leeds.
<P>
The command line arguments were: <BR>
<STRONG>latex2html</STRONG> <tt>-split 0 lj_advocacy.tex</tt>.
<P>
The translation was initiated by David Wagle on 1998-03-23
<!--===================================================================-->
<P> <hr> <P>
<center><H5>Copyright © 1998, David Wagle <BR>
Published in Issue 27 of <i>Linux Gazette</i>, April 1998</H5></center>
<!--===================================================================-->
<P> <hr> <P>
<A HREF="./lg_toc27.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../lg_frontpage.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="./marsden.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./jeffery.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
<!--startcut ==========================================================-->
</BODY>
</HTML>
<!--endcut ============================================================-->
|
