On Sat, Jun 18, 2005 at 04:53:03PM +0100, Timothy Murphy wrote: > Just to explain a little better what I mean. > What exactly is the basic aim of the anaconda developers? > In my view, it should be to ensure > that Fedora can get to the point of installation > on as wide a range of machines as possible. Sure, that's definitely got to be one goal -- although there's always the tension of adding junk to deal with bizarre corner cases vs. a nice straightforward clean install for the vast majority of normal situations. > That was always the aim of Linux distributions in the past, > with half-a-dozen different boot disks offered > for every conceivable situation, > together with driver floppies for special devices. And as I remember it, pretty much everyone hated that. But the truth is, the shift to CDs and modular kernels makes it so all of those drivers can be on one disk. > I follow the anaconda development mailing list (though not diligently) and > it seems to me that most time and energy is expended on what I would > regard as secondary matters, while what I take to be the primary aim above > is largely ignored. Your secondary matter is someone else's urgent crisis. But I think you're getting a skewed picture from the anaconda list, as the development isn't really centered around that. (Check the changelog to see what's actually been going on.) > > It does to me. Eventually, really old hardware and weird situations have > > to get dropped, or you get *more* excessive complication and cruft. You > > can't have it both ways. > I don't think that is true. I would imagine that if changing code at > critical points, one could add a clause to the effect that if the new > version does not work then one should fall back to the old. It's not that simple, because it's not just the installer -- it's the kernel, and hardware probing infrastructure, and more. And "clauses that fall back to the old version of the code" is pretty much the *definition* of crufty code. > For example, the kernel itself seems to be written to this principle. > I can't recall anything that used to work in the kernel > that has ceased to work > (admittedly, after researching choice of modules in some cases). Actually, sounds like the SCSI problems you're having are directly kernel related (although I didn't ever see a message about the exact SCSI hardware -- I may have missed it). > This is exactly what happened, anyway. > I've had problems before when grub became confused > about the various SCSI and IDE disks. > Basically, I think grub likes to call an IDE disk hd0 > unless persuaded otherwise. Yes. And recent versions of anaconda have code for doing that 'persuading'. > However, I didn't look into this. > All I know is that after upgrading to FC-4, > /dev/hda was no longer found, eg by fdisk. That sounds like the kernel to me.... > >> but after it I get innumerable errors > >> when trying to compile a virgin kernel. > >> Eg "make xconfig" does not work because qtlib is not found. > > This isn't an installer problem at all. This is a > > person-building-the-kernel problem. > It isn't an installer problem (I didn't say it was) Err, but your rant was about the installer.... > but it isn't a person-building-the-kernel problem either. > It is a problem with the x86_64 distribution > regarding the libqt library. > (There are various versions of this library on the system, > and it fails to link to the correct one.) Okay. I don't see how that illustrates that anaconda development is misguided.... -- Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/> Current office temperature: 76 degrees Fahrenheit.
