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

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

Removing LILO, Reinstalling MS-DOS

From: Stephen Britton,

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:

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:

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

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,

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

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:

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).
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.
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.
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.
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.
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.
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.
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.
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."
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.
Finally there is a strong possibility that the next product a given customer tries to switch to will be as bad or worse.

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