Salut je n'arrive pas à me désabonner du forum. J'ai suivi la procédure qui m'avait été indiquée...sans succès
Voulez vous me sortir de la liste de distribution SVP? --- Pierre Fortin <[EMAIL PROTECTED]> a écrit : > 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... > > === message truncated === ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
