*climbs up onto soap-box*
Installation:
As has been pointed out by many people, OSes are hard to install. This is
due mainly to the nature of the IBM-PC platform. This isn't ever going to
change for this platform. The solution is to have the professionals -- the
system integrators, like Dell and Compaq and all the way down to your local
computer shop -- do the work for the end-user. And at least with Linux, they
won't have to RE-install the OS every six months.
Of course, Linux VARs can create "Factory Restore CDs" which reproduce the
system configurations they develop for their systems. I would expect some
already do this. I know Red Hat has attempted to help this along with their
"KickStart" package (a poor imitation of Sun's JumpStart).
Upgrades:
Upgrading system software *WILL* break things. I don't see that changing
for a long time. However, Linux handles this better then most OSes I've seen.
For one, you at least *know* what's being upgraded. With Windows, you
download a Service Pack, run it, wait while it does its black magic, and then
reboot. You generally have no idea what it is doing, or why.
Linux also supports the idea of having multiple versions of shared libraries
installed at once, something Windows (so far) cannot do.
Maintenance:
Your average Windows user doesn't *do* system maintenance. I don't know why
we should expect them to do it on Linux, either. They wait until something
goes wrong, and then call a professional who knows what they are doing.
Point being: Windows isn't any better then Linux, here.
Learning Curve:
I hear it said a lot that Linux has a higher learning curve then Windows.
No, it doesn't. If you get a pre-packaged system with all your apps
preinstalled, Linux is just about the same as Windows. Now, if you want to
learn about system internals or mastery of the shell prompt, then yes, things
get more difficult. But they do on Windows, too! Ask a Windows user to edit
the Software\Microsoft\Windows\CurrentVersion\Setup key under the
HKEY_LOCAL_MACHINE branch of the system registry to point to the hard drive
copy of the installation cabinet files, and they won't have a *CLUE* what
you're talking about. CMD.EXE is no easier to learn then /bin/sh is. I could
go on and on.
System internals are hard, no matter what platform you're running on. The
Windows users afraid of the Linux command line are just as afraid of the
Windows command line.
Package Installation:
Installing packages into the user's home directory is a *BAD* idea. If the
user double-clicks on a package file in their GUI shell, it should fire up a
GUI package management program which immediately asks them if they want to
install it. If they answer "Yes", it should prompt them for their root
password or invoke a privileged installer. Unprotected system binaries are
why Windows has a virus problem. We don't want to do the same on Linux!
Configuration Files:
Someone suggested that the registry is a Good Thing. I *strongly* disagree.
The registry is unmanageable, poorly documented, unstable, a single point of
failure, unportable, a performance bottle-neck, and an attempt to impose a
universal solution for all problems. And that is just for starters. Some of
those (mainly documentation and stability) are because of a poor
implementation, but the rest are inherent in any single, large, monolithic
configuration system. Such systems should be avoided like the plague!
Let the programs use the configuration file format that suits them best.
ASCII text is strongly encouraged. Abstraction should occur in the user
interface -- for example, modular plugins to an easy-to-use configuration
system (like linuxconf).
Developing a standard library that provides an abstract interface to ASCII
text files in a standard format would be a Good Thing. This would allow
programs with simple needs to simply make use of the library, but wouldn't
force anybody to use it.
While I'm on my soap-box: Pushing XML as the solution to all our problems is
silly. "There Is No Silver Bullet!" Maybe XML would be a good format for a
standard configuration library, but don't get so hung up on it that you forget
that a tool is never going to solve problems -- it's the proper application of
a tool that makes the difference. :-)
Support Costs:
Some say "Linux isn't free -- you have to pay for all that support!"
They're right. You do. But you do on Windows, too. Microsoft charges $35 an
incident for Word and Win9X, $135 an incident for WinNT. Your system
integrator (e.g., Dell) is passing on the costs of installation,
configuration, and testing to you. Again, the point here is, Windows is no
better then Linux -- and Linux at least doesn't charge you for the software to
begin with.
Migration Costs:
Some say, "We cannot afford the downtime of a system migration!" They think
that if they switch to Linux, the transition period is going to kill them.
First, anyone who recommends completely scrapping all of your existing
systems at once in order to put in new ones should be *FIRED*. The reason it
is called a "migration" is that you gradually change over. Linux does this
very well. For example: Start off with a Linux firewall. Then move over your
Internet server. Deploy new intranet servers on Linux. When buying new
workstations, consider Linux instead of Windows. And slowly replace your
existing OSes with Linux.
Second, if you cannot afford downtime -- why the heck are you running
Windows? How can you afford to reinstall the OS every six months because of
registry rot if you cannot afford to replace it with a *working* system? How
can you afford the migration costs of Microsoft's forced upgrades, year after
year?
Office 2000 isn't compatible with Office 97 which isn't compatible with
Office 95. Windows 3.1 isn't compatible with Windows95 which isn't compatible
with Windows NT 4 which isn't compatible with Windows 2000.
Yet a C program written for AT&T Unix System 6 in the 1970s *will still
compile and run today*! Your migration costs are high with the *Windows*
platform. If you want to *avoid* migration costs, *switch to Linux*.
And furthermore --
*falls off soap-box as someone finally throws something at me*
--
Ben Scott
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
