On Sunday 13 December 2009, Michael Schwendt wrote: >On Sat, 12 Dec 2009 19:13:25 -0500, Gene wrote: >> I did have F12 installed, 64 bit version, but it was (pick a number * 10) >> slower than the 32 bit F10 install. > >Based on what measurements? What tools did you use to determine that it >was slower? click on a window close button, pick up empty coffee cup & walk to kitchen & refill it, get back to viewing the monitor in about a minute and another 30 seconds goes by before the window closes. That is slow by any definition. >> The only reason I loaded F12 in the first place was to get an updated for >> the man-in-the-middle exploit of openssh as supplied for F10. > >openssh? OpenSSL CVE-2009-3555 it seems. See below: >> You had a bit over >> 60 days to fix that from the exploit announcement in (I think) late Sept >> 2009, to the end of F10 support yesterday and when I queried fedora-list >> about it a couple of weeks back was essentially told to go pound sand, it >> wasn't going to be fixed. > >You were pointed at the related FAQ: >https://bugzilla.redhat.com/533125#c37 > >You might want to read the following, too, > https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/484417 >(which is only half the story as actually they applied an experimental >"fix" in middle November only to change their mind in early December when >they reverted the patch again). I've not figured out what they really did, I pulled the tarball for 0.9.8l and built it, so the point is moot even if it is scattered all over the system cuz fedora doesn't seem to use a sane --prefix= in the rpm builds. As for trash laying around, dev/sda will soon have another distro on it anyway. >None of this has anything to do with you trying an optional boot loader in >Fedora 10 more than a year after it had been published and requesting a >fix "asap". Perhaps that package has never worked for Fedora 10. Perhaps >it has not been tested by any substantial number of people even after its >release in Fedora 10, because if the primary [legacy] GRUB still does its >job, there is not much incentive to try the development version before it >will become the distribution's primary choice, too. The boot loader got involved because the *buntu derivatives are all using grub2 now, and I don't care what the call it "update-grub" or "grub- mkconfig", its broken, the whole design premise of an automatic grub configuration tool that they started with at gnu.org is broken. I now know enough about grub2 that I can hand carve a boot stanza for it that works just fine, so that point is also moot. What will really burn my ass is the first time I let a package manager update a kernel, and it fires off that steaming pile of crap and overwrites my hand carved grub.cfg so I can't boot any distro but the one that was running when the kernel was updated. Until I get around to carving a grub-mkconfig that actually works, I will cheerfully nuke it from all installs by hand just to protect myself. If you want to file a bz on it, be my guest, the problems are at least 2 fold. 1, The gnu.org version calls all boots for all distro's "GNU/Linux', so you have lost the identifier in the title/menuentry lines that tells you what distro this stanza will boot. RMS's politics have no place in this and should be forthwith removed by copying the title line from the old grub.conf. 2. It only scans the /boot partition of the distro its booted to, a major fsckup right there. Grub/grub2 is capable of booting any bootable partition that exists in the machine. But why, if they are going to give us this 'tool', doesn't it take say a list of bootable partitions in the form of the device.map file, but with the numbered partition, in my case (hd0,1), (hd1,1) and (hd3,1) which all contain bootable distributions as well, call it /boot/grub/boot.map. It would be far better designed to just translate an existing grub.conf to fix the new base 1 numbering (that I didn't understand in one of my previous rants) that grub 2 now uses as the partition address, then just copy the rest of the stanza verbatum etc etc. Wrap it in the {}, write it and go on till that grub.conf is out of entries, then goto the next (hd1,1), find that grub.conf and repeat till its out of bootable partitions in the "boot.map". That isn't rocket science. Its pure bash. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The NRA is offering FREE Associate memberships to anyone who wants them. <https://www.nrahq.org/nrabonus/accept-membership.asp> We promise according to our hopes, and perform according to our fears. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
