"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/


 Removing LILO, Reinstalling MS-DOS

From: Stephen Britton, sbritton@westnet.com

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!!

 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.

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

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.

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

Naturally this will make all of the data on the drive inaccessible -- but I suspect you already knew that was going to happen anyway.

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.

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.S. I tried talking him into taking Linux, but he's locked into the Windows mindset.

 Trying to convince someone of something is usually a losing proposition. Try to understand his real requirements -- and offer the best advice you can.

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.

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

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

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

I ask people to consider this tidbit in their long range planning. Truly optimizing for the present requires looking to the future as well.

-- Jim

 Running as root on Standalone Systems -- DON'T

From: griffin@ameritech.net

What advantages are there, if any, to running your single-user system as a normal user and not root?

 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.

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.

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.

The advantages are:

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.

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.

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.

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.

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.

However, none of that matters to the home user with root access to his own box.

-- Jim

 More on Netscape Mail Crashes

From: Chris, colohan@cs.cmu.edu

In http://linuxgazette.net/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).

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.

 These sound like excellent troubleshooting suggestions, recovery procedures and workarounds.

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

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

Consequently I will probably stay in a poor position to answer questions about NS's mail and news readers.

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.

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.

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:

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.

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.

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

Luckily we, Linux and free software users, are blessed with alternatives. These systemic problems are what I think we are really "free" of.

-- Jim

Previous "Answer Guy" Columns

Answer Guy #1, January 1997
Answer Guy #2, February 1997
Answer Guy #3, March 1997
Answer Guy #4, April 1997
Answer Guy #5, May 1997
Answer Guy #6, June 1997
Answer Guy #7, July 1997
Answer Guy #8, August 1997
Answer Guy #9, September 1997
Answer Guy #10, October 1997
Answer Guy #11, December 1997
Answer Guy #12, January 1998

Copyright © 1998, James T. Dennis
Published in Issue 25 of the Linux Gazette February 1998