Once upon a time, Paul Jakma <paul@xxxxxxxxxx> said: > My data-point is that I ran an x86-64 kernel on i386 F10 for a few > months until I got tired of yum not being able to update kernel > packages. The kernel side apparently works fine AFAICT. The .1% is > yum. No, it's the whole development environment. For example, if you need to build a kernel module, gcc on i386 is not capable of building for x86_64 (IIRC it isn't a gcc configuration issue, it is an issue with gcc itself). You could just always install the x86_64 gcc, but then you need all the development tools and libraries to match. "gcc hello.c" is going to generate native code, and native will still be x86_64, so you have to have the x86_64 shared libraries and support in place (and now you're back to a multilib system, which loses on RAM usage, disk space, install time, update downloads, etc.). Also, part of your justification was that in the "real world", people run some 32 bit anyway (like wine). Well, what happens with some of those "real world" binary modules people use, like nVidia? Do they work with a split 32/64 user/kernel space (and development stack somewhere in between)? If they don't, users are going to blame Fedora, not nVidia (or whoever else ships binary modules). Again, most of the Fedora people developing things like yum, anaconda, etc. don't appear to be interested in this; there just doesn't seem to be a significant benefit (okay, you save a little RAM, but for the majority of 64 bit systems, that isn't a big deal). If you think otherwise, nobody is stopping you from doing the work to make it happen, and if it proves to work and be a benefit, I bet it would be accepted. -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
