Date: Thu, 07 Jan 1999 14:42:42 -0800 From: Julian Elischer <julian@whistle.com> To: Nate Williams <nate@mt.sri.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 Message-ID: <36953862.59E2B600@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> <199901072214.PAA24446@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > And there is no way to upgrade the upgrade code? You have no control > over what the upgrade code does? You get new upgrade code with the upgrade, but that will only be used in the NEXT upgrade. > > C'mon, I have a *REALLY* hard time believing that your upgrading doesn't > allow for the possibility of running aribitrary commands. no the upgrade code didn't have the ability to run arbitrary code BEFORE booting into the new system. It has the ability to schedule arbitrary code to be run AFTER teh new kernel has booted (so that the arbitrary code is running on the same systemit was compiled on) but before the actual application starts, but that's too late for changing the bootblocks. > > 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. yes but that would require 2 upgrades in a row.. one to load the new bootblocks to install them, and one to load and run the ELF based system. I'm not saying it's impossible but it flies in the face of "don't annoy the custommer". In the end we may end up with a double upgrade, but that is a pain because we only retain 1 backwards revision on the machine so the custommer could not revert to the old system they were running after the 2nd upgrade should things go wrong with it. > > If it's not possible, then I guess Whistle screwed itself here by not > thinking ahead, didn't it? I admit we didn't consider in 1996 about replacing the bootblocks on the fly, but I think you'd be pleasantly surprised by just about every other facet ot the upgrades etc. :-) > > > 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. :-) >> > > 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. You may be right. That's a decision for 'marketting'. Remember that this is an 'appliance' that should "just work" so the custommer expectation is that they shouldn't have to do very much.... Mind you, a 'boundary' release between major branches of the code does have some advantages. > > 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?36953862.59E2B600>