The BFC Computing Weblog

There's a problem when running two X-displays with MythTV - some events on the non-Myth screen will steal focus and then the MythTV controls will no longer respond. This thread describes the problem well, but is now closed for comments.

Since then, mouse-switchscreen has been written, and solves the problem correctly. It's possible to bind the program to a hotkey.

In the end, I found it better to just run one display at a time since I couldn't prevent the focus stealing.

Redhat recently released a set of virtualized I/O devices for KVM, the kernel virtual machine. This short post will outline a method of converting a Windows Vista install (on KVM) to the new drivers using Virt-Manager. It has been tested on Fedora 11.

1. Make sure Vista VM is up to date on patches and the disk is error free.

2. Download drivers from Redhat network or here.

3. Mount the .iso file as a CD-ROM device.

Now you might think you can use the ‘Add Hardware Wizard’ here and add the drivers, add the hardware, and be good. I did. I wound up with an unbootable disk. Apparently Vista’s autodetection is required in this process. So…

1. Add a new network device of type ‘virtio’. Vista will do its “you’ve got hardware” routine and run you through all of its wizards. When it asks you for drivers, point it at the i386/2008 directory on the driver disc image. Yes, Yes, OK, Yes, Really, Continue, etc.

2. Shutdown the VM and remove the old ethernet controller. Boot up Vista and make sure the network works. You can conceivably skip this step for now if you want to make troubleshooting harder.

3. Add a new Storage controller. Leave the existing one as-is for now. You’ll have to pick a disk image you’re not using right now, or make a new one. Anything is fine, we’re not going to ever use it inside Vista. Do the driver dance again.

4. Shutdown Windows. Remove the storage controllers, and add a new one, type ‘virtio’, with your normal hard drive image. Take care of the old ethernet controller here too, if you ignored my previous advice.

5. Boot Windows normally. It should now be coming up on VirtIO disk and network drivers. If you get a bluescreen or a plea to use the RepairCD, something went wrong. Use the repair CD to restore to a previous restore-point and try again.

If anybody knows where to find a sound driver, please leave a comment!

For folks who are running the current development, or soon-to-be-just-released Fedora 11, you might find Firefox to be very crashy. It's not because it's the semi-controversial 3.5b4 version (which is excellent), it's because of a buggy library.

I'm running it with the Tree Style Tab and NoScript extensions, and can get a crash half the time when Session Restore is running, and almost all the time when I allow a site in NoScript.

If you run firefox from the console, so you get the debug messages, you'll see:

cairo-ft-font.c:554: _cairo_ft_unscaled_font_lock_face: Assertion `!unscaled->from_face' failed 

when the crash happens. I tracked this down through the Mozilla and Freedesktop bug systems to a problem with the Cairo graphics engine improperly disposing of fonts which it didn't own, for which a fix was incorporated last December. However, the version of Cairo shipping in Fedora 11 is older than that.

So, I applied the simple patch, fixed up the .spec, and put up some new RPM's for i386 and an SRPM for hackers and x86_64 users to build (rpmbuild --rebuild cairo-1.8.6-3.fc11.src.rpm).

I haven't tried cross-compiling from i386 to x86_64 before, and --target=x86_64 doesn't work, so if anybody can tell me how to do that short of learning mock, please leave a comment and I'll put up RPM's for that too.

The Redhat bug is here. Hopefully it gets accepted soon.

Here's a technology idea: combine a solid-state flash drive, a synchronization engine, advanced virtual memory techniques, and a portable hardware abstraction layer to create a portable computer state device.

The idea would be like this: you have a small hardware device that you bring with your anywhere. When you plug it into one of your computers, it would synchronize the filesystem states, restore memory images, and resume your computing environment the way you left it at the last location.

It's roughly equivalent to the idea of network computers, except you don't need the ubiquitous ultra-high-speed Internet that doesn't really exist (when wireless gigabit is pervasive, this would become passe).

Current reasons this can't work, using linux as the obvious OS to start with, include the lack of an abstract HAL (root drive, home drive, etc) and the lack of virtual-memory restore on a per-process basis. Lots of the other parts exist already.

Initial limitations would probably be a restriction to the same hardware architecture (x86, AMD64, ARM, etc), inability to deal with filesystem changes greater than the capacity of the SSD, and an inability to restore stateful network connections (an IP proxy might work around the last one).

One company has made an approach at this experience by running the environment directly on the portable device, but this forfeits local resources and demands power draws unachievable on an external bus (for simple connectivity). That approach may gain viability over time, though, but not yet.

Would you, gentle reader, use such a device?

KDE 4.2 looks like it's finally the right version to get me to use Linux as my daily desktop. 4.5 has more goodness baked in, 4.1 was insufficient, but 4.2 looks 'just right'. I used to be a GNOME user, but with GNOME's track towards Microsoft API's (mono) for its centerpiece applications I've gone over to KDE, and with its recent switch to LGPL I couldn't be more optimistic about its future.

For those who like to run official '-stable' versions of everything in Fedora, stop here. It'll be in Fedora 11 in a few months. Go read the warnings at the kde-redhat and the tracking bug if you want to know all the theoretical risks involved.

But for those eager to get on with things, I'll distil down what I think is the minimal command set to install the '-testing' release of KDE 4.2:

cd /etc/yum.repos.d

sudo wget http://blog.bfccomputing.com/files/kde.repo

sudo rpm -Uhv http://download1.rpmfusion.org/free/fedora/releases/10/Everything/i386/os/rpmfusion-free-release-10-1.noarch.rpm

sudo yum -y groupupdate kde-desktop

sudo yum -y update

(answering Y to importing GPG keys)

log out, log back in. You should be good to go.

I started with a working KDE 4.1 install, which wasn't easy either. If you haven't gotten that far first, be sure to do so. I have this in my notes from trial and error getting all the correct packages installed:

yum -y install kdebase kdegames kdegraphics kdemultimedia kdenetwork kdepim kdeplasma-addons kdeutils kipi-plugins PyKDE4 digikam-libs ebook-tools-libs kdebase-libs kdegames-libs kdegraphics-libs kdemultimedia-libs kdenetwork-libs kdepim-libs libgadu system-config-printer kdeaccessibility kdeartwork kdebase-workspace system-switch-displaymanager

but it may not be comprehensive (leave notes, please). Run 'system-switch-displaymanager KDM' to get the correct display manager selected. If your logins never succeed there are more packages to install. Unfortunately anaconda doesn't give a working KDE install, even if you select it at install-time.

To verify the Fedora 10 package downloads, you need the new key they're signing the Fedora 10 packages with, but it's only included in the -release rpm which you don't want to install on some other machines, say your repository mirror.

This works:

rpm --import 'http://pgp.surfnet.nl:11371/pks/lookup?op=get&search=0xBF226FCC4EBFC273'

I wonder why this is different than the -newkey key. Anyway, don't take my word for it, check the signatures to prove it for yourself.

Apple's Snow Leopard (10.6) operating system is due out in the next quarter according to slides shown recently at the LISA conference. It adds a small handful of features but it's mainly an architecture, performance, and bugfix release. Leopard (10.5) is pretty buggy and Apple readily admits it's not what an OS should be. So they're coming out with an update less than a year and a half since the last one, which is by most counts what Leopard should have been. This isn't really disputed, even Apple's name isn't for a new cat, this is the one with all the 'marks cleaned off'.

OK, so it's great that Apple's getting everything squared away so quickly, right? Yeah, it is if you've got recent hardware.

But what if you have a computer that was purchased in, say, the first half of 2006? It's going to have a PowerPC processor in it, and Snow Leopard doesn't support PowerPC. OK, so then you can run Leopard, which does support PowerPC. But, wait, Leopard is buggy, that's why they're fixing it.

OK, so you can run Tiger (10.4). Well, no, if you're going to be connected to a network you'd be foolish to do that; Apple only issues security updates for the current and previous versions of its OS, and with 10.6, 10.4 will go by the wayside. Within months there will be public exploits for your 10.4 machine available and the time to your machine being compromised is just a roll of the dice.

"Wait," you may be saying, "my machine is less than three years old and it's now unsupported?" "It's still under AppleCare warranty and I can't even get security updates?"

Yep, and there we see the tactical brilliance behind splitting the Leopard and Snow Leopard releases - Apple gets to book its revenue early on a not-ready OS, beat Microsoft to the market, and save a ton of money really only supporting one majoor version of its operating system. So, this doesn't really work out well for you? Just buy a new Mac, they're probably not going to do this again in three more years. Right?

This may be a dangerous gamble for Apple in a recessionary economic period, so perhaps they'll do the right thing and simultaneously keep their customer base. If not, Ubuntu 8/PPC isn't eligible for a commercial support contract but it'll run on your Mac and its security updates will be current for another two years. At that point your machine will be five years old and you can keep it around with debian or netbsd or if we're coming out of the downturn get yourself a brand new machine. By then you'll be so used to Ubuntu you'll have broad purchase options.

From today’s new Macbook announcement:

11:01AM Q: Concern about the glossy screens. Are you going to offer another option?
          A: Steve: We're going all glass -- we won't offer another version. 
          Phil: You offset the reflection by the brightness, and consumers love it. One of the great things about a notebook is you can turn it however you want!

I’ve used a Mac laptop since 1992 as my primary machine and often find myself using it in situations where I can’t actually rearrange the furniture or move the windows (Phil apparently lives in an opaque bubble). So I’ve always ordered a Macbook Pro with a matte screen, because my brain simply can’t see through the glare. Some people can, my eyes don’t work that way.

Yeah, their marketing images actually
show the reflected keyboard

So, today marks the end of availability of new Macs I can use. Since OSX doesn’t run on other hardware (securely) this means I can’t plan on using OSX into the future. I’ll keep a machine around for media work in the short term, but it’s obvious I need to get as much of my work moved over to Linux as possible if I’m going to have hardware that’s current technology.

With Apple’s primary focus on the iPod/Phone market, its draconian tactics there, and its inability to deliver a stable next OS release this is merely the last straw (if it were the only problem I’d consider investing in custom coatings, etc.) Thanks, Apple, it’s been a fun 16 years.

Update: Not just me.

From Fedora Weekly News:

Daniel P. Berrange laid it out there. “There is pretty much zero chance that Fedora 10 will include a Xen Dom0 host. While upstream Xen developers are making good progress on porting Dom0 to paravirt_ops, there is simply too little time for this to be ready for Fedora 10. So if you need to use Fedora 10 as a host, then KVM is your only viable option at this time. If you can wait for Fedora 11 (or use RHEL-5 / CentOS-5) then Xen may be an option for you.”

The basic issue is that the the virtualization groups are getting together on a standard kernel interface, paravirt_ops, and the Xen folks aren’t ready yet. Fedora 10 has a hard deadline, and the Xen group isn’t likely to make it in time.

Why Fedora 10 is important, is that Fedora 8 will stop getting security updates once Fedora 10 is released, per policy. When Fedora 9 came out, the Fedora Project told Xen users to hold off on Fedora 9, that Fedora 10 would have the Xen pieces. Had it told users at that time stop using Fedora they might have had a reasonable opportunity to plan for a chance, but at this point they have only weeks to get their systems off onto another operating system.

While RHEL/CentOS have always been billed as the ‘stable’ platform, many community-minded systems administrators run Fedora as a way to help find problems and improve the codebase. In return, they get more up-to-date packages and an expectation of being able to upgrade to new releases as they’re available.

Now, for the first time I can recall, Fedora has dropped its end of the bargain, for any folks who are using Xen virtualization. I know I don’t deploy any new servers these days that don’t use virtualization, and I doubt I’m highly unusual in that regard. Fedora thus stands to lose a great number of users, i.e. testers, trust and goodwill. After all, if one of the two major kernel flavors can get the axe, just about anything else can too. It raises the question of what Fedora provides, as a distribution. Sure, we understand that the upstream kernel isn’t ready, but is Fedora willing to merely have its feature set dictated by outside parties? This is as much a function of Fedora’s release-by-date rather than release-when-ready policy. They want to release approximately every six months, come hell or high water, and while momentum is desirable in a vacuum, sometimes the community might deserve some consideration as well.

The current expectation is that the Dom0 bits will be in kernel-2.6.28. By all expectations, this release will come about 90 days after 2.6.27 is released, or approximately mid-January, if not sooner. One would hope since the Xen kernel no longer requires a separate RPM package that when Fedora adopts 2.6.28 as its primary kernel (early Feb ‘09, perhaps) that Xen Dom0 support will re-appear.

So, to arrive at a detente, the most practical approach would be to extend Fedora 8 security updates until such a time as a Xen-Dom0 kernel is integrated into Fedora. Without argument, this will consume precious development hours among the Fedora development community. And Fedora can legitimately argue that it’s ‘for experimental use only’ and plausibly get away with not doing so. However, the practical reality of choosing this path is to lose community-sourced testing hours orders of magnitude larger than would be saved by continuing the updates. And since RHEL 6 will require a stable Xen base for its release, Fedora 10 with Xen is going to be very important to have well shaken-out for RHT.

On an RPM-based system, yum-utils provides a utility called ‘package-cleanup’. It has two useful options:

–orphans shows RPM packages that do not belong to any currently-configured repositories, and:

–leaves shows RPM packages for which there are no dependencies; that is removing them won’t trigger the removal of other packages. By default it’s concerned with libraries, but –all removes that restriction.

So, ideally you’d like to run:

package-cleanup –orphans –leaves –all

to get a list of all the packages you might want to consider for cleanup, say before or after an upgrade. But package-cleanup doesn’t support that.

So, here’s a little perl script, called leavesorphans.pl on my system that will run package-cleanup twice and print for you the intersection of the two sets:

#!/usr/bin/perl -w
          use strict;
          use warnings FATAL=>'all';
          
          use Data::Dumper;
          
          my @orphans = `package-cleanup --orphans`;
          my @leaves = `package-cleanup --leaves --all`;
          
          my (%orphans,%leaves);
          foreach my $orphan (@orphans) {
              $orphans{$orphan} = 1;
          }
          foreach my $leaf (@leaves) {
              $leaves{$leaf} = 1;
          }
          
          my (@matches);
          foreach my $orphan (keys %orphans) {
              foreach my $leaf (keys %leaves) {
                  if ($orphan eq $leaf) {
                      push (@matches,$orphan);
                      delete $leaves{$leaf};
                  }
              }
          }
          
          
          foreach my $match (@matches) {
              if ($match !~  m/Setting up yum/) {
                  print $match;
              }
          }
          
          

I recently ran it and found a few packages that were lingering on my system since Fedora Core 4, just wasting system resources. If all of your proper packages belong to a repository you can simply pipe the output of the command to xargs rpm -e. I’m not quite that slick, so I manually reviewed the list and kept the packages I had installed by hand.