Surprisingly stable, for the most part, but with a few nasties: . RPM broke completely at one point (md5 mismatch errors), necessitating manual extraction from an RPM of updated components. Was there a more graceful way of handling the changeover? . Radeon driver and kernel modesetting. This has been coming on in leaps and bounds, but it's still not quite there yet. The stock F11a kernel had no support, then there was support but it caused visual corruption, now it seems to work properly (2.6.29-0.252.rc8.fc11) but the radeon driver subsequently causes the system to lock hard when running anything OpenGL related (drm?). That final point was the cause of the next... . ext4 data loss. It's been many years since I lost an entire filesystem in normal operation, and that was not under Linux, but it happened yesterday after the aforementioned lockup. I had to hard reset, but the worst I expected was a journal recovery. Not so. In this case, the kernel first insisted there was no space left on the device (whereas there was actually over a 100GB), then another reboot later it failed to grok the filesystem at all, claiming it did not appear to be an ext4 filesystem. I can't say whether or not this is related to the now well publicised delayed allocation issue, or whether this will be resolved in the fixes promised for 2.6.30, but it has definitely put me off ext4 ... for now. Maybe I'll come back to it in a few years. I would question the prudence of pushing this as a visible anaconda option in the final release though, since some are undoubtedly bound to accept it as ready for production, and IMHO it isn't. . Speed issues. I noticed no discernible improvement in disk access speed (no benchmarks, just my impression), and the graphics subsystem was dog slow, but this was probably just an expected result of the current state of radeon. Booting seemed slightly faster, although maybe that was a purely psychological effect of being distracted by Plymouth? I seem to recall timing a cold boot at 60 seconds to the login prompt, which is OK for a 5400RPM EIDE laptop drive, but not stunning. IIRC I get that now on the currently installed Fedora 8 (2.6.26.8-57.fc8). Overall, the system felt decidedly laggy. . Compatibility issues. The newly pushed Thunderbird 3 reintroduced an age-old problem with saving draft copies on an IMAP directory (hangs forever). I can't remember what I did to fix it last time, but nothing obvious worked this time around. Naturally, my huge collection of plugins no longer work (something which seems to happen even with the most minor update, and which I find intensely irritating), most crucially the Enigmail plugin, which seems to lack any compatible update (64 bit system). I did grab one which looked like it was supposed to work, but plugin manager complained about the build being incompatible (gcc issue?). That's a blocker for me, since I absolutely must have GPG support, so I had to revert back to Thunderbird 2. . Suspend/Hibernate ... broken again. I must admit this really confuses me. If it works once, then why shouldn't it always work? Very, very annoying. . Pulseaudio stuttering and proper device control ... It's quite funny seeing mplayer suggest that my 2GHz AMD64 system, with Audigy 2 audio, "might not be fast enough" to play media. The "tsched=0" setting does help somewhat, but this really needs to be addressed. Another issue is the lack of equaliser controls (bass/treble) which is provided by the DSP on the card. I really want to see more than just "Master" when I open volume control. No, seriously, I really, really do. A post elsewhere from one of the devs, suggested that equaliser controls should "never be part of the software", which I found to be a rather arrogant position, since how else is one supposed to control the equaliser settings on a pair of headphones connected to a laptop, especially when the card actually provides this function in the hardware? I spent a few minutes trying to hack support in using something called swh and ladspa, but whatever this is supposed to do it didn't work here - either that or I just failed to grasp the incredibly convoluted and confusing Pulseaudio configuration settings. This is something that really needs to be built in. No human should ever need to endure the torture of Pulseaudio's dotfiles. Until PA can actually play audio without stuttering, and provide the same degree of device control as ALSA (easily), then I'm afraid I won't be using it. Ending on a positive note ... radeon, when it actually worked, was highly impressive. I found no discernible difference in 3D speed between it (under F11a) and the proprietary fglrx (under F8), although I'm sure a more empirical benchmark would have revealed a difference in numbers. It gives me real hope that fully accelerated Free Software 3D graphics drivers are now actually a reality. As for everything else, well it's still early days yet, but my overall impression is "OK", nothing more. Plymouth stands out in my mind as a compelling motive, along with various improvements to libgpod - which are unavailable to older releases due to a cascade of unresolvable deps, and I have become rather enamoured with KDE4.2, so I suppose this may be the release that finally compels me to dump F8. I just hope some of the above issues are addressed by the time it goes public. One request I would like to throw out there, as a RFE, is the ability to specify *keyfiles* instead of a password, when anaconda is setting up an encrypted filesystem with cryptsetup. My current arrangement requires me to manually edit the initrd thus: echo Setting up disk encryption: SecureKeys cryptsetup luksOpen /dev/sdb1 SecureKeys mkdir /SecureKeys mount -t ext3 /dev/mapper/SecureKeys /SecureKeys echo Setting up disk encryption: takeMScrypt cryptsetup luksOpen /dev/sda2 takeMScrypt --key-file=/SecureKeys/takeMScrypt.key echo Closing encryption keys volume: SecureKeys umount /SecureKeys cryptsetup luksClose SecureKeys sda is a USB keychain, with a built in MicroSDHC card reader. sda1 is "/boot", unencrypted. sda2 is "/" on an LVM volume encrypted with the kefile on sdb1. sdb is a MicroSDHC card, with the key store on sdb1, which is itself password encrypted. So when this boots, I'm asked for a password once, which unlocks the key store, and uses keyfiles in that key store to unlock the other filesystems, then closes and unmounts the keystore, so the MicroSDHC card can be physically removed (and possibly hidden). How easy would it be to build something like this into anaconda? Thanks for listening. -- Regards, Keith G. Robertson-Turner -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
