"Ernest N. Wilcox Jr." wrote:
This entire thread started out from a message triggered by not running
ldconfig after upgrading some libraries. To imagine that it degraded to
this level of FUD and disinformation is absolutely amazing. Let's look
at the statements made in just this reply (Sorry Ernest, I'm really
_NOT_ trying to pick on you, you're just the last responder)
> Well, for the most part. You can put in a Kernel update, then
> reconfigure LILO to enable you to access it without the install
> procedure, but you do of course have to restart the system to use the
> new Kernel.
Absolutely correct. Kernel installation can be carried out while the
system is running. Feel free to install and remove as many kernels as
you'd like, it won't hurt a darn thing.
However, you MUST beware of messing with files which /etc/lilo.conf
mentions. If any of those files are moved, updated, etc., you MUST
rerun /sbin/lilo to update the boot information. Further, if you make
changes to /etc/lilo.conf, you also must run /sbin/lilo to reflect those
changes.
Failure to rerun /sbin/lilo after either of these things WILL cause your
system to fail to boot next time.
> As for the software part, I guess that I am a creature of habit. So
> often in Win31 and 32 I had to do a restart to insure that any new
> drivers were properly installed, I guess that I still do it as much out
> of habit as because I think that it is safer to restart any time I
> change my system to insure that it will still start propoerly.
Please remember that only the kernel (and it's attendant modules)
implement device drivers (well, there's X, but that hardly counts).
Apart from upgrading a kernel or replacing hardware, there is very
little reason to EVER reboot your machine.
Upgrading Apache does not necessitate restarting your machine -- simply
stop the HTTP daemon and restart it. Upgrading system libraries doesn't
require restarts either, they will be loaded the next time you start a
program requiring them.
One of the very fun "tricks" you can show a Windows user (especially one
who's fought network configuration) is to change the IP address of an
interface. Under Windows, that's an automatic reboot. Under Linux, you
simply drop the interface and bring it back up. Unless users are
currently using that interface, nooone will likely even notice that it
briefly disappeared.
People need to understand that the crap we've all dealt with under a
Windows world simply doesn't exist under real operating systems.
Applications do not require reboots. Changes to libraries do not
require reboots. This is probably hard for many to get used to, but
it's a measurement of just how much we've been short-changed by other
operating systems.
> As for a complete version update of the OS, you must remember that the
> operating system works with your hardware at a very fundamental level so
> you don't have to. Often, it may use binary addresses to access hardware
> drivers in memory, and the hardware must use these drivers as well, to
> communicate back to the OS. Much of the system software is loaded and
That's the kernel. Application software DOES NOT interface with
hardware directly. EVER. NEVER. The notion of resource allocation and
protection is absolutely central to a multi-user operating system. If
application software talked directly to the modem how would you ever
detect whether another application had it open? How would you limit the
people who could use the device?
> unloaded as needed to and from memory to conserve resources. To do this
> quickly, the system keeps track of where on the HD these software
> components are located, and uses this info to do its work. When you
> upgrade, all this info changes, and the OS cannot find what it needs to
> do its work, and BANG! Nothing works, and the system is halted (Locked).
Linux maps libraries into virtual memory (either real of swap depending
on the state of your system). Changing libraries behind it's back will
NOT cause application problems like you describe. Try upgrading glibc
while logged in. Can you do it? Of course. Currently running
applications will continue to use their already mapped library while
newly started applications will use the new library.
Further, application faults should not be causing your system to lock
up. If it does, it's a bug and should be reported to the proper
people. Application failures should never cause system failures
(unless, of course, that application is init).
> This last is not either complete or exact, but I think it is essentially
> correct. This is why you must use a boot disk to do an upgrade, so that
> the OS being upgraded is not the one running in memory, and the info
> being used is not changed while the upgrade proceeds. I hope this helps
> a little,
I have a really hard time with this last part. I'm one of those people
that really hates sitting through the installation process when I have a
perfectly good operating system right in front of me. Why _shouldn't_ I
be allowed to simply "rpm -Uvh *" and have it install those packages
I've named? Certainly the packaging system should take care of removing
all remnants of the old package and installing the new! If it doesn't,
it's a bug plain and simple.
Let's get past all of the Windows-centric thinking that we've become
accustomed to. Full reinstalls are rarely necessary. Reboots are
rarely necessary. Applications do not crash the operating system.
--
Steve Philp "The Internet is like crack
Network Administrator for smart people..."
Advance Packaging Corporation --Arsenio Hall
[EMAIL PROTECTED]
