From owner-cvs-all Thu Jan 7 14:56:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21928 for cvs-all-outgoing; Thu, 7 Jan 1999 14:56:30 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21920; Thu, 7 Jan 1999 14:56:28 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id PAA02910; Thu, 7 Jan 1999 15:55:58 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id PAA25135; Thu, 7 Jan 1999 15:55:57 -0700 Date: Thu, 7 Jan 1999 15:55:57 -0700 Message-Id: <199901072255.PAA25135@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/conf Makefile.i386 In-Reply-To: <36953862.59E2B600@whistle.com> References: <199901072037.NAA22536@mt.sri.com> <199901072101.OAA22809@mt.sri.com> <36952F5F.2781E494@whistle.com> <199901072214.PAA24446@mt.sri.com> <36953862.59E2B600@whistle.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > 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. Sounds like you have to do 'upgrades'. > > 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 should, because it's possible that you would need to move /etc files and such. But, stating what it *should* be able to do at this point is a moot point. > > 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.. Which is IMO the only 'acceptable' technical solution, and one many large companies have done, for people that are even more clueless than the Whistle owners. :) > I'm not saying it's impossible but it flies in the face of > "don't annoy the custommer". Or customer even. :) > 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. Doesn't it seem like no matter how far we try to think ahead, something always pops up that we never considered. :) > > > 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. State their getting 2X performance, and the internal disk is being replaced by something that is twice as big or something. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message