On Tue, 29 Jul 2003, Tom Duerbusch wrote:

> My take on multiple images is two fold.
>
> But first, the disclaimer:
> This assumes you have sufficient resources in the first place to do
> this (normally real memory).
>
> 1.  I don't know this to be true with Linux, but the Unix types have
> always been leary of having multiple applications running on the same
> box.  First, they say that they can't guarentee performance, then they
> start talking about an application corrupting the memory of another
> application.  So, one application per box if you want reliability.  I
> haven't had the experience of memory problems in Linux, yet, so I still
> tend to believe this.

Linux doesn't handle memory very well. My Athlon has 512 Mbytes of RAM,
and most of the time it works really well. However, I sometimes copy
large - 600 Mbytes or more - files, either from disk to disk or across
the LAN. When that happens, RAM gets filled with this data and
performance is really bad for a while, even when the file processing is
over.



>
> 2.  Once an application is running and is running good, it should
> continue to run correctly until something external happens, like putting
> on maintenance.  So, why put on maintenance, other than security
> patches?  A new application may need a different gcc library or such.
> The origional application, if not fully tested with the new changes, may
> fail in production.

Third-party software aside, this tends not to happen with Linux. At
least with commercial distros, people are paid to fix things without
causing such problems.

When you do full distro upgrades, you upgrade everything and go through
your QA routine.

As we've seen in the past few hours, there can be problems with
third-party software requiring specific versions of, potentially old,
libraries. Mostly, there are compatibility libraries included to allow
you to do this.

If you go the "I'll just create this little symlink and see if it
works," then you really are on your own. If it breaks guess who did it?
The good news is the pieces are all yours.

Sometimes it's happened in RHL that you needed compatibility libraries
from a prior release.


If vendor certifications are important to you, then life becomes more
difficult.


>
> At least VM makes it a whole lot easier to define, maintain and control
> multiple machines.

Even then I can imagine that over time, the number of "standard
configurations" will proliferate.

I discovered recently that people are still using Red Hat Linux 6.2.
Their applications all work on it. it's a good stable release of RHL 6.2
and it works on their hardware.

Unfortunately, Red Hat's not shipping fixes for it any more, and it is
in need of fixes. Still, if it's properlly shielded it's probably no
worst them MSWare.

Come to think of it, I installed RHL 6.2 myself a week or so ago.

I'm sure people here will be in that position wrt SLES7 or RHL 7.x in
time: the cost of disrupting it will be too much to contemplate.



--


Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.

Reply via email to