Re: [tlug] longest uptime boxes

[Tod McQuillin <devin@example.com>]

On Mon, 28 Oct 2002, Scott Robbins wrote:

> If you upgrade FreeBSD with make world, it's considered good practice to
> update the kernel as well (actually, before installing the new world)
> and this too requires a reboot.

This is the most significant difference between Linux and BSD unix.

Linux is a kernel -- to make a complete OS it must be packaged together
with programs which run under the linux kernel; GNU utilities like ls, mv,
cp, tar, and other linux-specific utilities like mount, ps, ifconfig, and
fsck.

Development of the linux kernel and of other software that does with it to
make an OS is largely decoupled.  So it is very common to upgrade the
linux kernel on a system without touching any of the other installed
software.  Sometimes this is fine, and other times things break because
new kernel functionality was added (or removed) and the programs which use
it (or don't) aren't changed to match.

In the BSD world, the entire OS is developed and maintained as a single
unit.  So when the kernel is changed, necessary changes to the programs
which use the changed part of the kernel are also made.

As with linux, it is possible to upgrade just the kernel without touching
the rest of the OS, but just as with linux, it can lead to problems if you
do.  The difference with BSD is that upgrading the rest of your system to
match the running kernel is easy to do and is standard practise when
upgrading.

> Actually, the make build world part is best done in single user mode,
> which although it doesn't require a reboot would make the machine
> inaccessible to outsiders during the time of building world, which can
> take over an hour (on slow machines, a LOT longer.)

It's not necessary to recompile your FreeBSD system or kernel in single
user mode.  The procedure goes like this:

1) upgrade your system sources to the latest versions from whichever
branch you are running (FreeBSD-STABLE, aka RELENG_4, FreeBSD-CURRENT, or
one of the security branches tied to a particular release (4.6, 4.7, etc))

2) 'make buildworld' -- this recompiles everything except the kernel and
stores the compiled binaries under /usr/obj

3) 'make buildkernel KERNCONF=YOURCONF' -- this recompiles the kernel
using your kernel configuration file and stores the compiled binaries
under /usr/obj

4) 'make installkernel KERNCONF=YOURCONF' -- this moves your current
kernel and modules to a backup directory and installs the new kernel you
built in step 3 into the root directory.

5) reboot into single user mode.  This accomplishes two things -- first,
it verifies that the new kernel installed in step 4 boots and runs
correctly (if it doesn't, you can revert to the old version and figure out
what went wrong).  Second, it makes sure the minimum number of processes
are running, so that running programs won't get confused when things
change underneath them in step 6.

6) 'make installworld' -- this installs all the programs you built in step
2 into their proper places.

7) 'mergemaster' -- this allows you to merge in changes to configuration
files in /etc without losing your existing configuration.  If new options
or defaults have been added, mergemaster allows you to make the same edits
to your installed files in /etc, without losing your own customisations.

8) finally, reboot again normally back to multiuser mode.  This lets all
the new programs you installed in step 6 be started in the normal way.

Everything up to step 4 can be done without rebooting or stopping normal
processing in any way.  The downtime is limited to how long it takes to
complete steps 5-7 (for me, usually about 15 minutes).

> A quote from FreeBSD Unleashed (which, as it's not an "official" FreeBSD
> publication is not respected by some, but still probably has merit)
> "Remember, a system with 350 day uptime either means a system that has
> been sitting unused in a closet for a year or a system that has not been
> conscientiously upgraded to keep up with security bulletins"

This is probably true.

> (hrrm, actually, that doesn't necessarily make sense--one would think
> that security patches can be successfully installed without kernel
> upgrades)

It depends on the patch.  Sometimes the security hole is in the kernel
itself, like maybe a bug in a system call that can allow any user to crash
the system, or a number of other possibilities.  See
http://www.freebsd.org/releases/4.6R/errata.html for an example of what
kinds of things can go wrong.  (4.6 was an unusually bad release for
FreeBSD -- all kinds of security problems and other bugs, both in BSD and
in third party code, were discovered at just about exactly the wrong time
in the release schedule.)

Back to your original question -- which is faster, FreeBSD or Linux --
there is no correct answer.  There are significant differences in the guts
of each -- VM system, scheduler, network stack, etc., that make each
perform better on some loads, worse on others.
-- 
Tod McQuillin