Recently, I came across a blog post about how to install a LiveCD version of Red Hat’s upcoming Fedora 9 release onto a USB stick, leaving space on the stick for data to persist between reboots.
Impressed by the persistent USB LiveCD fun and partition encrypting installer improvements, I chose to throw caution to the wind and load up Fedora 9 Beta on my main notebook, replacing the Hardy Heron Beta install I’d been running–quite stably–for several weeks.
Read on for the testing details, but the bottom line for Fedora 9 is more or less the same as with previous Fedora versions: Fedora can indeed be used for anything. Its primary purpose is to serve as a leading-edge development platform for Red Hat’s initiatives. As Red Hat confirmed very clearly last week, providing a mainstream desktop/notebook operating system is not one of their product goals.
While I’ve very recently called on Red Hat (and Novell) to address mainstream Linux users more directly, I can certainly respect their decision to focus on their bread-and-butter products. What’s more, even if they aren’t productizing it, Red Hat’s desktop and notebook work does continue, and is definitely evident in other, more end-user focused distributions–such as the Ubuntu release, which I returned after spending two weeks with Fedora 9.
Spending Time with Fedora 9
As I mentioned above, it was Fedora 9’s support of USB stick-based persistent LiveCD deployments that enticed me to download the in-development distro, and when I tried it out for myself, it worked great. Fedora 9 booted up from the 2GB USB stick I used, and, through the virtue of solid state, did so a lot more quickly than CD-based LiveCD images do. I used my portable Fedora 9 system to browse the Internet. I downloaded some things, and I installed a piece of software, too. I tried rebooting the system, and, sure enough, the changes I’d made did persist.
Next, while perusing the Fedora 9 Beta release notes, I saw that Fedora 9 now offers a partition encryption option at install time. It’s been possible to set up a Linux system with encrypted partitions for some time now, but only Debian and Ubuntu had implemented it as an install-time option.
Installation on my trusty ThinkPad T60 was smooth, and the encryption part boiled down to checking off an option box. I booted up and keyed in my encryption passphrase. Everything seemed to work, including my wireless network.
I hit the Web, and found that Flash and Java didn’t work properly for me. For Flash, I hit the same bug that Linus did–YouTube videos wouldn’t play. As for Java, the StatTracker applet for my Yahoo-hosted fantasy basketball league wouldn’t load.
I was prepared for these snags, however, since I know that Red Hat and Fedora are focused on pushing the all-free software envelope wherever possible. As a result, Firefox came pre-configured with the LGPL (Lesser General Public License) Swfdec-Mozilla plug-in, in lieu of a pointer to Adobe’s Flash download page.
I downloaded Flash from Adobe, and I put off downloading Java from Sun. Sadly, at the time I was testing Fedora, I was already more or less out of contention in my fantasy basketball league.
Next, I applied all the available updates (since Fedora 9 was still in development, there were many). I restarted, and found that my X server wouldn’t start. Annoyingly, Red Hat’s usually great fail-safe display mode didn’t kick in, either. I had trouble with this when I tested Fedora 8, and the fix required me to twiddle with a config file to force my way into fail-safe mode. After I got my X back, I installed the RadeonHD driver that my notebook requires, and I was back in business.
I turned next to installing the KVM virtualization software and Red Hat’s virt-manager virtualization management tool. I used the virt-manager tool to create a virtual machine, and I hit another familiar snag. As in my tests last year of RHEL (Red Hat Enterprise Linux) 5, I found that by policy, SELinux (Security Enhanced Linux) wouldn’t allow the virtualization application to read files in my home directory, where I’d instructed the setup tool to create the hard drive image file for my VM.
Like I wrote in that RHEL 5 review:
RHEL 5’s SELinux policy expects images to live in /var/lib/xen/images, and images stored elsewhere–such as ours—require re-labeling to avoid SELinux errors.
While this was a good opportunity to see RHEL 5’s new SELinux Troubleshooter in action, it would have been helpful if RHEL’s virtualization manager had given us a heads up about this earlier.
I ended up tossing SELinux into permissive mode, which records and flags the activities it’s been instructed to deny, but doesn’t deny them. Even though SELinux can be a pain, I’m a believer in MAC (mandatory access control) enhancements for operating systems, and I’m rooting for them to succeed.
Feature wise, the combination of KVM and virt-manager is nowhere near as good as VMware Workstation, but it serves the same basic functions, and it’s free. The Windows XP VM that I created under Fedora 9 performed well, and the fact that KVM is built into the system is a major plus. One of my pet VMware peeves is having to compile and recompile drivers, and the fact that KVM is part of the Linux kernel means never having to think about drivers.
Fedora 9 may no longer power my primary notebook, but I’m not done with it. I’m looking forward to digging into the distribution’s PolicyKit and PackageKit frameworks, and spending time with the much-needed FreeIPA project, which rides along with this release of Fedora. Stay tuned.
jebpages 