Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jan 1999 15:14:22 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        Nate Williams <nate@mt.sri.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/i386/conf Makefile.i386
Message-ID:  <199901072214.PAA24446@mt.sri.com>
In-Reply-To: <36952F5F.2781E494@whistle.com>
References:  <199901072037.NAA22536@mt.sri.com> <Pine.BSF.3.95.990107124507.3875I-100000@current1.whistle.com> <199901072101.OAA22809@mt.sri.com> <36952F5F.2781E494@whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > > changing the bootblocks is not always an option.
> > 
> > Sure it is.  If you can upgrade the OS, you can certainly upgrade the
> > bootblocks.  I see you complain about this alot, but this is no harder
> > than typing 'dislabel -B wd0' (or sd0..)
> > 
> > Besides, you can't boot off the old bootblocks with an ELF kernel
> > anyway.
> > 
> > If you're willing to jump to an ELF kernel remotely, then you should be
> > willing to upgrade the boot blocks remotely.
> > 
> > Nate
> 
> Nate you obviously didn't hear ALL of the discussion...
> 
> The Interjet upgrade process doesn't include code to upgrade the
> bootblocks, so we (Whistle) are stuck forever needing to support
> (in some way or other) the old bootblocks in the field. 

And there is no way to upgrade the upgrade code?  You have no control
over what the upgrade code does?

C'mon, I have a *REALLY* hard time believing that your upgrading doesn't
allow for the possibility of running aribitrary commands.


Nate

> Interjet owners may upgrade their Whistleware(TM) at any time or 
> they may decide to NOT upgrade it.

Sure.

> We can't MANDATE that they
> upgrade. We need to ensure that an Interjet sold 2 years 
> ago can upgrade in 2001 to the latest whistleware(TM), 
> however since the CODE installed in 1996 can't upgrade 
> the bootblocks we need to ensure that the old bootblocks
> can find something in the new release to boot.

Or you can upgrade the bootblocks on that hardware.  If you can install
and run software, then you can upgrade the bootblocks.

If it's not possible, then I guess Whistle screwed itself here by not
thinking ahead, didn't it?

> Of course it's not FreeBSD's job to make things easy for me, 
> so that's ok, but I think that since Linux uses /Linux, and 
> NetBSD uses /NetBSD and OpenBSD uses (I think) /OpenBSD, 
> using /FreeBSD would make us more 'in line' with the others, 
> and also backwards compatible with systems that are set up 
> with old bootblocks.

Didn't your mother tell you that 'if all your friends jumped off a
bridge, should you do it also' argument growing up.

There's no technical reason for it, only polticial ones.

> No matter what FreeBSD does, we will probably have a 3rd stage 
> loader called "kernel". We may also have an intermediate release
> that you must upgrade to if your release is earlier than
> some cuttoff point if you are upgrading beyond that point, so 
> that you first upgrade to a version that knows how to upgrade 
> the bootblocks, but consider that most of our custommers don't 
> know what a 'byte' is before you make glib commnts such as "but 
> this is no harder than typing 'dislabel -B wd0' (or sd0..)" 
> and also consider that there is no shell interface.
> 
> Asking a custommer to upgrade twice in a row for a single upgrade
> is a big 'custommer satisfaction' thing, that must be taken
> very seriously.

Symantec did this with Visual Cafe, and Intuit did this with Quicken.
The former has a couple hundred thousand users, and the latter has an
installed base larger than all of FreeBSD, so I don't think this is
an 'unacceptable' solution.



Nate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901072214.PAA24446>