463 lines
22 KiB
HTML
463 lines
22 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<title>The Answer Guy Issue 25</title>
|
|
</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>
|
|
|
|
<!-- =============================================================== -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../gx/ans.gif" alt="" border=0 align=middle>
|
|
The Answer Guy
|
|
<img src="../gx/ans.gif" alt="" border=0 align=middle>
|
|
</A></H1> <BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
Starshine Technical Services, <A HREF="http://www.starshine.org/">
|
|
http://www.starshine.org/</A> </H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<H3>Contents:</H3>
|
|
<ul>
|
|
<li><a HREF="./lg_answer25.html#lilo">Removing LILO, Reinstalling MS-DOS</a>
|
|
<li><a HREF="./lg_answer25.html#root">Running as root on Standalone Systems -- DON'T</a>
|
|
<li><a HREF="./lg_answer25.html#netscape">More on Netscape Mail Crashes</a>
|
|
</ul>
|
|
|
|
<p><hr><p>
|
|
<!--================================================================-->
|
|
|
|
<a name="lilo"></a>
|
|
<h3><img align=bottom alt=" " src="../gx/ques.gif">
|
|
Removing LILO, Reinstalling MS-DOS
|
|
</h3>
|
|
<P> <B>
|
|
From: Stephen Britton, <A
|
|
HREF="mailto:sbritton@westnet.com">sbritton@westnet.com</A>
|
|
</B> <P><B>
|
|
My parents just told me that I have to
|
|
give our extra machine (a 486 running Red Hat 4.1)
|
|
to my younger brother, who only knows Windows.
|
|
I have formated the drive with MS-DOS, but I
|
|
can't seem to figure out how to remove LILO. I
|
|
recall reading somewhere that it can be done by
|
|
c:\fdisk /mbr But that doesn't seem to be working.
|
|
Please help, he is returning to College next week!!
|
|
</B> <P>
|
|
<img align=bottom alt=" " src="../gx/ans2.gif">
|
|
That should do it. However -- which version
|
|
of MS-DOS are we talking about. This option
|
|
was introduced in MS-DOS 5.0. Although it
|
|
wasn't documented at the time it is widely
|
|
used to recover from a variety of boot
|
|
viruses.
|
|
<P>
|
|
If that that doesn't work -- boot from a Linux
|
|
floppy -- zero out the whole partition table
|
|
and MBR (dd if=/dev/zero of=/dev/hda -- for
|
|
a primary IDE, or of=/dev/sda for the primary
|
|
SCSI and count=1 (or 2 or so)).
|
|
<P>
|
|
Then you can boot from a DOS installation floppy
|
|
and it will insist that you run fdisk and will
|
|
treat the drive as though it was brand new and
|
|
previously unformatted/partitioned.
|
|
<P>
|
|
(Technically you only have to zero out or
|
|
put anyting other that 0x55AA as the last two
|
|
bytes of the MBR -- that's the signature that
|
|
tells FDISK that this drive has been previously
|
|
partitioned. However, it's just easier to zero
|
|
out the whole mess.)
|
|
<P>
|
|
Naturally this will make all of the data on the
|
|
drive inaccessible -- but I suspect you already
|
|
knew that was going to happen anyway.
|
|
<P>
|
|
Alternatively -- if fdisk /mbr doesn't work --
|
|
you should find out *why*. If this is an early
|
|
version of DOS -- you should probably try to
|
|
get a copy of 5.0 or later (or consider Caldera's
|
|
OpenDOS). I suppose you could also consider
|
|
installing Win '95, considering the likelihood
|
|
that your brother will need access to TCP/IP
|
|
utilities like web browsers and some e-mail
|
|
package.
|
|
<P>
|
|
On the one hand I hate to push some further down
|
|
the throat of the snake -- on the other hand we
|
|
should always do our best to act in the best
|
|
interests of our customers -- even when they're
|
|
our pesky brothers.
|
|
<P>
|
|
<img align=bottom alt=" " src="../gx/ques.gif">
|
|
<B>
|
|
P.S. I tried talking him into taking Linux, but he's
|
|
locked into the Windows mindset.
|
|
</B> <P>
|
|
<img align=bottom alt=" " src="../gx/ans2.gif">
|
|
Trying to convince someone of something is
|
|
usually a losing proposition. Try to understand
|
|
his real requirements -- and offer the best
|
|
advice you can.
|
|
<P>
|
|
It may be that Windows is the best environment
|
|
for him. It may also be that there are over-riding
|
|
constraints that force him to choose a Windows
|
|
compatible platform.
|
|
<P>
|
|
I think that many organizations are now "chained" to the
|
|
Microsoft aggenda by their current investment in their
|
|
existing data files (all their spreadsheets, documents,
|
|
and many of their small, departmental mailing lists, and
|
|
databases are locked into various versions of the proprietary
|
|
.DOC, .XLS, and other data formats).
|
|
<P>
|
|
Microsoft clearly intends to maintain this state. I
|
|
guess that is has been the core of their strategy for the
|
|
last five years (since about the release of Win 3.0 or 3.1).
|
|
<P>
|
|
(It is also not unique to them -- most major commercial
|
|
hardware and software vendors have tried to "lock" their
|
|
customer into upgrade paths. Companies like DEC, IBM,
|
|
and HP have each had their VMS, MVS, MPE OS' with this
|
|
aggenda. Consequently their efforts at Unix have often
|
|
been "skunkworks" -- and have been highly politicized for
|
|
over a quarter of a century).
|
|
<P>
|
|
I ask people to consider this tidbit in their long range
|
|
planning. Truly optimizing for the present requires
|
|
looking to the future as well.
|
|
<P>
|
|
-- Jim
|
|
|
|
<p><hr><p>
|
|
<!--================================================================-->
|
|
|
|
<a name="root"></a>
|
|
<h3><img align=bottom alt=" " src="../gx/ques.gif">
|
|
Running as root on Standalone Systems -- DON'T
|
|
</h3>
|
|
<P> <B>
|
|
From: <A
|
|
HREF="mailto:griffin@ameritech.net">griffin@ameritech.net</A>
|
|
</B> <P><B>
|
|
What advantages are there, if any, to running your single-user
|
|
system as a normal user and not root?
|
|
</B> <P>
|
|
<img align=bottom alt=" " src="../gx/ans2.gif">
|
|
If you're absolutely perfect, you never make a typing mistake or
|
|
issue a wrong command, or a right command from a wrong directory
|
|
with the wrong arguments, *and* you only run perfect software,
|
|
with no bugs in it at all, *and* you are totally disconnected
|
|
from the world (you don't get any e-mail, never use netnews, or
|
|
IRC etc) -- then you *might* be sort of safe running as root on
|
|
your system.
|
|
<P>
|
|
If you simply don't care about your data and you like the idea
|
|
of rebuilding your system configuration from scratch then throw
|
|
all caution to the wind and go for it.
|
|
<P>
|
|
However, for the vast majority of us, it's the most minimal bow
|
|
to prudence to log in as an unprivileged user for the vast
|
|
majority of work you do at your system.
|
|
<P>
|
|
The advantages are:
|
|
<ul>
|
|
<li> Your normal user account can't accidentally
|
|
damage vital system files with any normal
|
|
command. The most common cause of data loss
|
|
and downtime is operator failure. When I
|
|
worked on the tech support lines at Norton
|
|
Computing (the largest publisher of DOS and
|
|
Mac data recovery tools) the accidental
|
|
deletion calls were more common than all other
|
|
causes combined. Even on Unix and other
|
|
multi-user system the system administrators
|
|
(or "operators") are the primary cause of
|
|
downtime and data loss. It simply makes
|
|
sense to minimize these risks.
|
|
|
|
<li> Programs you are running (buggy, or even
|
|
trojan horses and viruses) can't readily
|
|
damage system files. Software bugs are
|
|
the second most common cause of data loss.
|
|
Trojan horses and viruses are a rarity
|
|
in the Unix world -- precisely because
|
|
the prevailing custom is to run software
|
|
with minimal privileges. When it comes to
|
|
software that legitimately needs privileged
|
|
access (like the Red Hat rpm system when
|
|
it's used to update or install new packages),
|
|
many sysadmins run new software on a "sacrificial"
|
|
system or in a "chroot jail."
|
|
|
|
<li> Even programs that are reasonably O.K. may
|
|
vulnerable to deliberate attacks. If someone
|
|
uses 'write' to ANSI-bomb you (re-writing the
|
|
keybindings in your terminal/console driver for
|
|
malicious purposes) or exploits some 'feature' of
|
|
IRC or your mail reader to execute code on your
|
|
behalf, you'd like to limit the damage they can do.
|
|
</ul>
|
|
The disadvantages mostly relate to convenience. A typical
|
|
microcomputer user from a DOS, Windows, OS/2, MacOS, AmigaDOS,
|
|
CP/M or similar background is used to being able to edit any
|
|
file and change any setting directly and quickly.
|
|
<P>
|
|
By maintaining the discipline of only doing administrative tasks
|
|
from a 'root' login -- and all of your other work from one or
|
|
more 'user' accounts you are forced to pause and consider the
|
|
implications of what you're doing.
|
|
<P>
|
|
It's also nice that you can partition your work into distinct
|
|
domains -- you can always play games from your 'player' account
|
|
-- and none of those games can damage you're thesis project, or
|
|
financial records, or whatever.
|
|
<P>
|
|
Personally I think this could use some improvement. I'd like to
|
|
see a system whereby by each user is implicitly the manager of a
|
|
group of "roles." For single-user home systems this would be
|
|
basically the same as using your root account to create new
|
|
psuedo users for yourself. On multi-user systems it would
|
|
delegate the task of creating new roles and rolegroups to the
|
|
user --- so that each user's "base account" in effect becomes an
|
|
administrator of this own roles.
|
|
<P>
|
|
The problem I see with that is that there's no support in Unix
|
|
for it. I think it would take alot of work to build a set of
|
|
tools to support it (and many of these tools would have to be
|
|
SUID 'root' in traditional Unix systems -- or would require some
|
|
totally different lower level support such as a variant of a
|
|
"capabilities" system. In any event these tools would be very
|
|
security sensitive -- and early versions would probably be the
|
|
cause of numerous exploits.
|
|
<P>
|
|
However, none of that matters to the home user with root access
|
|
to his own box.
|
|
<P>
|
|
-- Jim
|
|
|
|
<p><hr><p>
|
|
<!--================================================================-->
|
|
|
|
<a name="netscape"></a>
|
|
<h3><img align=bottom alt=" " src="../gx/ques.gif">
|
|
More on Netscape Mail Crashes
|
|
</h3>
|
|
<P> <B>
|
|
From: Chris, <A
|
|
HREF="mailto:colohan@cs.cmu.edu">colohan@cs.cmu.edu</A>
|
|
</B> <P><B>
|
|
In http://www.linuxgazette.com/issue24/lg_answer24.html, you suggest
|
|
removing the ~/.netscape tree to stop Netscape Mail from crashing.
|
|
I have had the same problem several times, and it does not appear to be
|
|
anything in that directory -- it is the mail files themselves. It
|
|
appears as though Netscape will occasionally put a wee bit of corruption
|
|
in your ~/nsmail/[Inbox, Trash, etc.] files, which prevents it from
|
|
reading them. And it crashes when it encounters any corruption in these
|
|
files. It also seems to crash if your trash gets too large. (Anything
|
|
over 1MB seems hopeless).
|
|
</B> <P><B>
|
|
So one solution is to back up your mail elsewhere, and erase your mail
|
|
directory. Then Netscape will create new, valid, empty mail folders,
|
|
and stop crashing for a while. Another solution is to open the files
|
|
yourself (they are just text files), and erase any messages that look
|
|
suspect.
|
|
</B> <P>
|
|
<img align=bottom alt=" " src="../gx/ans2.gif">
|
|
These sound like excellent troubleshooting suggestions,
|
|
recovery procedures and workarounds.
|
|
<P>
|
|
I believe I also mentioned that my e-mail is far too important
|
|
to me to entrust to Netscape (or any "new" product). For
|
|
years I used 'elm' and before that it was 'mush' (mail user's
|
|
shell). The switch from 'elm' to MH (using emacs' mh-e and Gnus
|
|
interfaces) was nerve-wracking. (I deal with over a hundred
|
|
messages a day -- and it's at the core of my business that I
|
|
"keep up" on administration and security issues for my customers).
|
|
<P>
|
|
My biggest customer (another consultant in a different specialty)
|
|
has also made this switch, after over a decade of using emacs'
|
|
RMAIL. As you can imagine there have to be some pretty extensive
|
|
advantages to a package to warrant changing from one client to
|
|
another. (Merely having a "prettier" interface and a few bells
|
|
and whistles isn't nearly enough).
|
|
<P>
|
|
Consequently I will probably stay in a poor position to answer
|
|
questions about NS's mail and news readers.
|
|
<P>
|
|
As for the fact that NS crashes when encountering corruptions
|
|
in folders and messages -- that's just poor quality control and
|
|
poor coding. As usual the issues of "time-to-market" and
|
|
"pretty interface" dominate the development of commercial products.
|
|
<P>
|
|
The nature of the computer software industry practically guarantees
|
|
that the most widely used commercial products will have bugs of
|
|
this sort. This is the result of a set of corporate priorities
|
|
that don't match typical customer priorities -- and is a byproduct
|
|
of the selection process by most software is purchased.
|
|
<P>
|
|
I could go on about this for many pages. Since I worked in the
|
|
software industry for a long time -- I had a lot of time to
|
|
observe the process first hand. (Since I was doing tech support
|
|
I also had an abundance of free neural cycles to think about the
|
|
issues, as well). Here's a few observations that will help explain
|
|
my conclusion:
|
|
<ul>
|
|
<li> Software companies sell features. They only make money
|
|
on product sales and upgrades -- and the margins are
|
|
much better in upgrades than in initial sales (since
|
|
many, possibly most, upgrades are direct revenue --
|
|
and no "cut" goes to the channel distributors and
|
|
retailers).
|
|
<li>Most software marketing is directed to channel
|
|
distributors, retailers, and fortune 1000 corporate
|
|
purchasing agents. Most of it is not directed to
|
|
end users and home customers. These intermediaries
|
|
largely determine the pricing and availability of
|
|
most commercial software, and the advertising that
|
|
goes to the end-user. The priorities of these
|
|
intermediaries are: high sales, low product return
|
|
rates (RMA's). The purchasing agents at Merisel
|
|
and Egghead don't do detailed requirements analysis
|
|
on behalf of their customers.
|
|
|
|
<li> Product returns are most tightly correlated with
|
|
how long the customer has had the product before
|
|
becoming dissatisfied with it. This is why "ease
|
|
of use" and "ease of installation" are so important
|
|
in commercial software. If the vendors can keep
|
|
the majority failures from occuring for 60 to 90
|
|
days -- very few customers will return the product
|
|
even if the publisher's policies allow it.
|
|
|
|
<li> There is much more focus on corporate sales than
|
|
on retail for most shrinkwrapped software. This
|
|
is due to high rates of piracy among home users
|
|
and the obvious observation that every "customer"
|
|
contact costs money (sales and tech support time).
|
|
So one successful sale at TransAmerica costs much
|
|
less than 10,000 individual sales to home users
|
|
and SOHO markets.
|
|
|
|
<li> Most corporate software users have little say and
|
|
relatively little interest in what software they
|
|
use. They are told what do so -- and usually don't
|
|
question that. Corporate purchasing agents get
|
|
plenty of political pressure from managers and
|
|
executives but usually neither the purchasing
|
|
agent nor the manager spends much time "in the
|
|
trenches" with the software that's being used.
|
|
|
|
<li> Managers are far more worried about being "wrong"
|
|
than being "right." An excellent product from an
|
|
unknown source is considered a much higher risk
|
|
than a mediocre product that gets good press and
|
|
comes from a large, well-known source.
|
|
|
|
<li> The computer industry press can't sell much copy
|
|
by talking about "old" products. They also can't
|
|
depend on any significant amount of advertising
|
|
unless they maintain close, positive, relatiionships
|
|
with their major advertisers. Most of their
|
|
advertisers are hardware and software companies.
|
|
|
|
<li> Because the writers in most of these magazines
|
|
are working with new (usually pre-release or "beta")
|
|
software or versions they have no opportunity to
|
|
discover the bugs that take two or three months to
|
|
show up in typical use. In addition most of these
|
|
writers either don't use the products they review
|
|
extensively, or tend to rely on earlier versions
|
|
for their production and critical work. Almost
|
|
no one is a full-time professional journalist in
|
|
the computer industry -- and those that are in
|
|
this position are in a rather poor position to
|
|
do in depth evaluation of anything other than
|
|
word processors.
|
|
|
|
<li> Despite these limitations -- which almost gaurantee
|
|
that we should take software reviews with a large
|
|
block of salt -- these reviews in major magazines
|
|
become the focal point of most discussion on the
|
|
topic. By the time a given customer has purchased,
|
|
installed, configured, and learned a given product
|
|
it's usually too costly (emotionally and in time)
|
|
to "start all over."
|
|
|
|
<li> The fact that a large number of commercial packages
|
|
store some or all of "their" data (not "yours" -- but
|
|
"theirs") in proprietary formats also increases the
|
|
risks and costs associated with switching.
|
|
|
|
<li> Finally there is a strong possibility that the next
|
|
product a given customer tries to switch to will be
|
|
as bad or worse.
|
|
</ul>
|
|
When you go through all of this -- even if you don't agree
|
|
with half of the observations -- it's easy to see why so
|
|
many people live in quiet desperation, hating their most
|
|
important software.
|
|
<P>
|
|
Sadly it takes *really* bad software to fail as a result of its
|
|
bugs. dBase IV comes to mind. It doesn't take much for really
|
|
high quality software to fail as a result of poor marketing
|
|
(or the superior marketing and industry dominance of competitors).
|
|
DESQview comes to mind.
|
|
<P>
|
|
By contrast almost all free software is chosen by end-users
|
|
based on recommendations from other end-users. It is produced
|
|
by people whose only rewards are: access to their own tool
|
|
to solve their own problems, the satisfaction of having lots
|
|
of users, and some chance for fame and sincere admiration.
|
|
They gain nothing by claiming more than they deliver (except
|
|
more e-mail with more support questions).
|
|
<P>
|
|
Luckily we, Linux and free software users, are blessed with
|
|
alternatives. These systemic problems are what I think we are
|
|
really "free" of.
|
|
<P>
|
|
-- Jim
|
|
|
|
|
|
|
|
<!--================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H4>Previous "Answer Guy" Columns</H4></center>
|
|
<P>
|
|
<A HREF="../issue13/answer.html">Answer Guy #1, January 1997</A><BR>
|
|
<A HREF="../issue14/answer.html">Answer Guy #2, February 1997</A><br>
|
|
<A HREF="../issue15/answer.html">Answer Guy #3, March 1997</A><br>
|
|
<A HREF="../issue16/answer.html">Answer Guy #4, April 1997</A><br>
|
|
<A HREF="../issue17/answer.html">Answer Guy #5, May 1997</A><br>
|
|
<A HREF="../issue18/lg_answer18.html">Answer Guy #6, June 1997</A><br>
|
|
<A HREF="../issue19/lg_answer19.html">Answer Guy #7, July 1997</A><br>
|
|
<A HREF="../issue20/lg_answer20.html">Answer Guy #8, August 1997</A><br>
|
|
<A HREF="../issue21/lg_answer21.html">Answer Guy #9, September 1997</A><br>
|
|
<A HREF="../issue22/lg_answer22.html">Answer Guy #10, October 1997</A><br>
|
|
<A HREF="../issue23/lg_answer23.html">Answer Guy #11, December 1997</A><br>
|
|
<A HREF="../issue24/lg_answer24.html">Answer Guy #12, January 1998</A>
|
|
<center><H5>Copyright © 1998, James T. Dennis <BR>
|
|
Published in Issue 25 of the Linux Gazette February 1998</H5></center>
|
|
<P> <hr> <P>
|
|
<!--================================================================-->
|
|
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif" ALT="[ TABLE OF
|
|
CONTENTS ]"></A> <A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="lg_bytes25.html"><IMG SRC="../gx/back2.gif" ALT=" Back "></A>
|
|
<A HREF="./doyle.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<!--startcut ======================================================= -->
|
|
</body>
|
|
</html>
|
|
<!--endcut ========================================================= -->
|