On Tue, 2003-01-14 at 08:00, Pierre Fortin wrote: > 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..
Your letter (quoted from you above at top) came back to me with the point that you consider upgrades to be important. I'm saying fine, but if that is your stance and you are having problems, you need to also evaluate a from-scratch install in comparison to the upgrade. Yes, maybe the install approach DOES have problems, but that's why we are here too. Not only that, but you are using a production distro with the aim of trying to get work out of it. What I've been saying to you is a direct reflection of not only my own experiences, but also a slew of other users on both the expert and newbie lists when it comes to upgrading. Historically, an upgrade from a previous distro just has not produced good results; for just about anybody. Now you come on the cooker list here complaining with problems and also stating that you went from 8.2 to 9.0, upgrade style. From what I'm hearing, it doesn't even sound like you've *tried* a from scratch install. Quite frankly, this just does not make any sense to me whatsoever. Now I agree with you that everybody should be able to do upgrades from one distro to the next. I also agree that world hunger should be abolished and all democrats purged from politics. But that don't mean that it's going to happen. The fact of the matter is that the process is not finished yet; Mandrake is a work in progress, and will likely continue to be that way for a bit longer, especially in light of the current situation over there. So back in the real world....you are attempting to get a production install. Let's look at the situation: We have two installation methods; A and B. With A, we have one variable, which is the 9.0 CD. With B, we have two variables, the 8.2 distro and the 9.0 CD. B is more complicated than A. Since we ONLY have A and B situations to deal with, then we need to use A as the base case since it is less complex. It also logically follows that A has a higher probability of success since it is a less complex scenario. Again, nothing but common sense. Now, on the cooker list here, we are attempting to solve problems before they hit production. In order to do that, we need to do the same thing; eliminate the variables as much as possible. That means going to less complex and starting from there. > > 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? What are you talking about? I'm saying install 9.0 on your system fresh, SAME system for both installations, and compare those installs (upgrade and fresh) side by side and then see how it pans out. > 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? First of all, I'm not talking about all a20m users; I'm just talking about you right now. The situation is way complex enough without bringing the rest of the world into the equation. What I would do is evaluate your laptop alone first, and get a working control scenario for that, if you can. But to answer your last question; yes, I think it's possible to have a base case that relates across more than one a20m, if the following parameters are met: 1) Same bios settings 2) Same manufacturer/speed memory; verified known good by diagnostics 3) Same mobo with same chipset revisions from same manufacturing plants on mobo 4) Same addon peripherals with same chipset revisions from same manufacturing plants 5) Known good mobos evaluated with diagnostics 6) Known good processors evaluated with diagnostics 7) Same hard drives; make and model And anything else as identical as possible that I did'nt think of. > > 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 you've got two installations on the same machine, how will one hide anything on the other? Two seperate installs, two seperate sets of bug reports. Two evaluations. > 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)." That's true, which is all the more reason that you don't heap more possibilities on the situation and make your job more complicated. Doesn't make sense. > > 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 You keep on diagnosing the problem like you are, and I'll continue using the same principles I learned professionally over 14 years ago. I'm telling you that you need to go to a less complex gradient. > -- 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? Good questions, and I don't have solid answers except for the first one; get a bigger hard drive to use for testing. Large enough to hold two intallations. I got 9.0 on a 4 gig partition the other day with space to spare. Of course, YMMV depending on individual needs. As for tools, when you are comparing, all bug/normal/security fixes should be in place before any evaluation takes place. For the new install you can start filling out bug reports as you find them; that's assuming you've run diagnostics on your hardware prior to 9.0 installation. I don't know what to tell you about the LM82-90 situation; I wouldn't even look at it without getting a handle on a virgin LM90 install. --LX -- 같같같같같같같같같같같같같같같같같같같같같같같같같� Kernel 2.4.18-6mdk Mandrake Linux 8.2 Enlightenment 0.16.5-11mdk Evolution 1.0.2-5mdk Registered Linux User #268899 http://counter.li.org/ 같같같같같같같같같같같같같같같같같같같같같같같같같�
