On 14 Jan 2003 06:04:19 -0500 Lyvim Xaphir <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-01-11 at 10:56, Pierre Fortin wrote: > > > Respectfully, then WHY did Mdk add the 3rd option (2nd upgrade method) > > -- if upgrades are so bad, Mdk should have removed the existing one, > > not added a 2nd one... > > You misunderstand. The objective is not to eliminate or deprecate > upgrades; the objective is to get a base case for comparison; and in so > doing, perhaps something that works better, as a side effect. Lyvin, you normally have quite clear responses... can you translate this one for me... my point is that there should be no reason for anyone saying "but you should do an install [if you want' stability/reliability]" -- I can't quite grok what you're saying.. Like this: > > > Format your partitions and reinstall 9.0 pristine. Then reevaluate. > > > > I don't see how this will help: > > - ohphone/openh323 is not compiled properly -- the developer tried to > > blame me initially. > > - CD is a "supermount issue"; happens on pristine installs too > > - sound has been a problem for a long time -- threads galore on that > > - ~/.kde is a known issue even on pristine installs > > - CUPS problems are a nearly daily thread on cooker/expert > > > Does anyone have a tool to compare a pristine install to an upgrade? > > That would provide some useful information compared to the > > unscientific "do a pristine install" approach. If upgrades are a > > problem, pristine installs over them won't help get to the bottom of > > the problem(s)... > > Hah! Unscientific, eh? Why would you try to troubleshoot a problematic > upgrade without installing a clean 9.1 beta in parallel (in another > partiton on the same hardware) to provide a base case for comparison > purposes? The reason for a Cooker mailing list subscription is mainly to > TEST the beta's. That being the case, and you having problems, then you > need to be comparing upgrades to clean installs. It is very unsmart > evaluation procedure to compare a problematic upgrade to another > problematic upgrade, especially if they are the same upgrade. You > always need a base case; in science we call that the control. Therefore > you need to have two hard drive areas available on the same hardware to > install 9.1 to in order to make comparisons, if indeed you are > evaluating upgrade/install or troubleshooting the upgrade functions of > cooker. That's just common sense. Ummm.... maybe you misses the point that this is on an IBM ThinkPad A20m -- there are NO differences between "Joe's" A20m and mine (except that my memory is maxed out) -- do you know where I can get alternate hardware for this box? So, are you saying that given identical hardware, there can't be a "base case" somewhere for all A20m users to compare to? And yes, I know that we can install different packages; or are you also saying that installing "SuperFOO" negates the possibility of a base case? It's disconcerting to hear on one hand that Linux allows modular approaches, and on the other, that Mandrake requires everything to be a single, unseparable entity... > > Besides, isn't cooker an "upgrade" system; I don't see much "do a > > pristine cooker install" being recommended -- though I may be missing > > those. > > You've just seen one; and the reason I recommended it was not so that > you could have a production quality system; since we are dealing with a > beta and the entire thrust of the cooker list discussion is to locate > problems; therefore if you are evaluating an upgrade then you need a > base case to compare against, otherwise your results are tainted by > contamination from the previous install. (and lack of a control) and if these contaminations are always hidden by installs, how will the upgrade process ever get fixed??? > If there is no difference, then *fine*; that means you have eliminated > previous distro contamination as a possiblility. That's one advantage > of the control case -- finding out where the the problems are NOT. But... as I've been saying for many years, as a result of years of experience trouble shooting: "Until you've found *and* fixed a problem, you can NOT discount *any* possibility; what you gratuitously discount will likely be the source of the problem(s)." > By installing fresh you also isolate problems that are possibly inherent > in the installation routine, but that may not show up in the upgrade > procedure. Disagree... you just hide/mask the problems -- besides, if there isn't enough disk space to do paralle installs, just how is one to compare...? Even if there is space, what tools exist to help narrow down possible sources of problems? > > We won't fix the problems if we keep hiding them, or running from > > them... > > Very true; and we will never fix anything at all without some modicum of > troubleshooting skill. Agreed. > > The gist of this thread is that we need Mdk to work on reliability and > > stability more than eye candy... > > Yes, and once again that requires proper troubleshooting skills. "proper" IMO is the ability to say: "hmmm... let's figure out what is causing the problem -- if it doesn't immediately lead to HOW it was caused, at least we have some base knowledge to add to until we find how it was caused..." In cases of not enough disk space, installing over a problem just hides/masks it... > > I'm about to hammer on WalMart for the lack of support from their > > supplier(Microtel) of Linux systems... > > The open source world is struggling right now to be profitable and open > source at the same time. A better expenditure of time and energy would > probably be in fixing cooker problems; or reporting them. If WalMart > gets too much flak about their Linux distributors, they could possibly > cease distribution altogether and go back to winblows only. This was handled offline, though I agree with you to a point... if Microtel aren't responsive, *they* will ruin it for us... > > If Linux distros and suppliers don't care about those things that got > > Linux where it is, then the movement is doomed, and I won't stand by > > and let it happen if I can help it. > > To a certain degree I agree; we probably just differ on the timeframe. I > just don't believe in spanking the baby. More importantly I don't think > that as the movement (and companies) get started that there is going to > be a wealth of resources to get worldwide support done. After Linux > becomes a reknowned and profitable business venture, these startup firms > will probably be able to have the resources to provide support. For now > I don't think that they do, and as a result the onus of the support > burden probably will have to be taken up by the Mandrake/Linux > community. That can be our contribution to helping Linux businesses get > off the ground with minimum resources. Agreed, where the community can.... but bad hardware is squarely in the hands of the distributor -- sorry if that wasn't clear... > > --LX > Pierre
