(This story bereft of hyperlinks as I don't want to give anyone more free publicity than they deserve).

I was recently contacted by a 'Marketing Research Executive' (boy, we sure love our important-sounding titles!) from 'Packt Publishing'. They were asking me, out of the blue, to post on this blog a review of a book they're publishing, which was vaguely related to something I wrote about a couple of times.

Long-term readers will note that, if there's one thing lacking in the annals of this here august publication, it's book reviews. Nary a book review will you find in my archives, search you ever so long. (For a start, I don't read tech books. Never have, probably never will. For the benefit of other Marketing Research Executives, I don't read self-help books, 'business books' full of incomprehensible jargon, or motivational books either.)

Apparently this is no reason for Packt Publishing to think that, possibly, I won't be interested in spending my time, entirely uncompensated other than an 'electronic copy' of the book (oh, joy!), to write a 'review' of their tome, thus providing it with enormous quantities (ahem) of free publicity. Also, apparently, no reason for them to think I might be a bit unappreciative of them contacting me entirely out of the blue to request this.

So, yes, PP, please knock this off. It's not hilariously evil, but it's annoying and not particularly classy. Send review copies to proper journalistic outlets who have paid staff reviewers who do this sort of thing for a living. Or if you're going to try and get yourself free publicity from random bloggers you found on Google, at least have the common lack of decency to offer a reasonable backhander. I wouldn't have taken that either, but at least would have felt the game was being played according to the long-established traditions, and there's nothing I like more than a good long-established tradition...

(and if you're considering publishing a book via PP, do stop and consider that they'll probably be sending out annoying emails along these lines to all your friends and acquaintances. Of course, you may think that's just them doing a good job, but hey...)

So this week we round out the Fedora 13 Test Day schedule, which has seen us run the gauntlet from NFS, through color management and SSSD, scale the heights of Graphics Test Week, and will see us come to a triumphant finish with the Preupgrade Test Day on Thursday 2010-04-29 and the Xfce Test Day on Friday 2010-04-30.

These are two juicy topics: preupgrade is the recommended method for upgrading from one Fedora release to the next, and is widely used. We also really need to have it working properly at release time, so we need your help to test and make sure it is! Xfce is one of the most popular 'alternate' Linux desktops, and has a very dedicated Fedora SIG which works hard to provide a smooth experience and live spin, and has organized the Test Day to make sure the Fedora 13 Xfce experience is second to none. So please come out and help us polish off these final Fedora 13 features!

As always, the Test Days will run all day in the #fedora-test-day channel on Freenode IRC. If you're not sure about IRC, read the guide or use WebIRC. If you can't do the testing on the Test Day, you can still run through the tests and provide your results earlier or later; you'll just miss out on the real-time IRC discussion, but that's okay. You can do the Xfce testing with a live image which will be provided on the Test Day page. Obviously this isn't possible for the preupgrade testing, but you can test it in a virtual machine if you don't want to (or can't) mess with your real Fedora installation.

Testing is easy and there's lots of guidance on how to do the testing and file your results on the Wiki pages - you don't need any special skills to help out! Even if you get stuck, there will be QA team members, developers, and other testers on IRC to help you out. The more testing we get done the more polished Fedora 13 will be for everyone.

CORRECTIONS: i) the initial version of this post incorrectly stated that Jesse Barnes works for Red Hat; he actually works for Intel, and it's been updated to reflect that.

ii) Fedora does in fact ship the GLX 1.4 backport, in Fedora 12 rather than Fedora 13. Thanks to Kevin Kofler for that information.

Some of you may have read about a memory leak that cropped up very late in Ubuntu 10.04 development process. They kindly put this phrase in their explanation of the bug:

"One possible solution is to roll back the GLX 1.4 enablement patches, and the patch which caused the memory leak to appear. These GLX patches were produced by RedHat and incorporated into Debian, they were not brought in due to Ubuntu-specific requirements"

which can obviously create the impression that the patches in question actually come from Red Hat Enterprise Linux, or from Fedora. (The explanation has since been updated everywhere it appears, AFAIK).

The 'GLX 1.4 enablement patches' do come from Fedora: Fedora 12 includes X server 1.7, with GLX 1.4 backported from X server 1.8. (This post previously suggested Fedora did not include these patches). However, the actual patch that caused the problem in Ubuntu was not part of the GLX 1.4 backport, but was an attempt to fix this bug. Sometimes X would crash when Clutter-based apps closed. Fedora did actually suffer from this bug too.

However, Ubuntu and Fedora took different approaches to fixing it. Ubuntu seems to have taken one of Jesse Barnes' early attempts to fix the problem (Jesse works for Intel, not Red Hat as this post previously stated). In the end, though, if you read the upstream bug, Jesse ceded to Kristian Høgsberg (who, for the record, works for Intel), who provided a better fix which was committed to upstream. For Fedora 13, we took Kristian's fix, not any of Jesse's attempts. This was included in xorg-x11-server-1.8.0-7.fc13 . That seems to have caused a couple of problems with compositing managers.

-7 was sent as a candidate update for F13, got bad Bodhi feedback (as you'd expect) and was withdrawn; it never went into the 'stable' F13 repo (the one from which the final F13 will actually be built). The bugs were fixed by adding one more upstream patch, from Michel Dänzer, to xorg-x11-server-1.8.0-8.fc13 . That build has good feedback, and was pushed to F13 updates two days ago.

So in summary our processes worked very well, we didn't jump on an incomplete fix, we didn't push the initial upstream fix to the 'stable' F13 because our feedback system made us aware of the problems it caused, we did push the fully-working fixed package when it was confirmed ready, and we were never at any point subject to the memory leak issue.

Ubuntu took a different approach to fixing the problem, and hit their own bug with their chosen fix (the memory leak), but they also seem to have resolved their bug quickly, so their process appears to be working well too.

The wonderful Olivier Blin of Mandriva has come through with his patches for making the psb video driver for Poulsbo (GMA 500) chipsets work on newer versions of X.org. He reports success - including 3D - with X server 1.7.

I'm hoping this will mean I can provide fully-accelerated packages for Fedora 12 soon; I have to request an F12 branch in RPM Fusion, though, as I previously suppressed it to avoid anyone trying to use a driver that wouldn't work. So once that's created, I'll push the packages through.

F13 is more uncertain. It has an even newer X server - 1.8 - which Olivier doesn't have to test against, so we don't know if that works. It also has a newer Mesa which Olivier believes is likely to cause problems (due to the removal of a function the psb Mesa driver calls). He has an idea for a hack to get around this, but hasn't put it in place yet. So it's possible we won't be able to get a driver for F13 at all, and if we do, it'll likely be missing 3D acceleration, at least to start with. Still, better than a kick in the teeth.

There's a secondary problem with F13, which is that as far as RPM Fusion is concerned, F13 doesn't seem to exist. Fusion Rawhide is tracking Fedora Rawhide, which - under No Frozen Rawhide - is F14, not F13. There is no F13 branch in Fusion. So as far as I can tell, at present, there's just no way for me to provide F13 packages in RPM Fusion. It's very difficult for me to provide packages outside of RPM Fusion too, because I rely on the akmods system for packaging the kernel module, and that lives in RPM Fusion; with there being no F13 branch of RPM Fusion, there's no F13 akmods configuration - there's nowhere to source a set of the necessary packages from RPM Fusion for the akmods system to work. So, yeah, that sucks. Will report back if the situation improves!

I wrote up a recap of Graphics Test Week for the mailing lists, thought it had some interesting data so I'm reprinting it here.

The insanity that is Graphics Test Week is now over, so it's time for the recap!

https://fedoraproject.org/wiki/Test_Day:2010-04-13_Nouveau https://fedoraproject.org/wiki/Test_Day:2010-04-14_Radeon https://fedoraproject.org/wiki/Test_Day:2010-04-15_Intel

We had a great turnout again; thanks to everyone for testing. Here's some interesting numbers I just pulled out...

f11 nouveau: 104 tests, 42 bugs - ratio 0.40 f12 nouveau: 53 tests, 34 bugs - ratio 0.64 f13 nouveau: 78 tests, 26 bugs - ratio 0.33

f11 radeon: 55 tests, 46 bugs - ratio 0.84 f12 radeon: 61 tests, 81 bugs - ratio 1.33 f13 radeon: 48 tests, 33 bugs - ratio 0.69

f11 intel: 23 tests, 21 bugs - ratio 0.91 f12 intel: 29 tests, 31 bugs - ratio 1.07 f13 intel: 38 tests, 38 bugs - ratio 1.00

The 'ratio' is the number of bugs per test. Obviously there's wiggle room here; different people report different bugs, and some of the drivers implement features the others don't (and hence have more 'surface area' for bugs). But I think they're quite fun anyway. Nouveau and Radeon both regressed from f11 to f12, according to the numbers, and got better than either previous release for f13 (at Test Day time). Intel has stayed fairly steady. According to this analysis, Nouveau wins the 'least buggy driver' contest by a fair margin, which is interesting! For F13, it has half as many bugs per test as Radeon, and a third as many as Intel. (Of course, I'm sure some of our erstwhile devs would argue it could fairly be renamed the 'least crack-addled hardware manufacturer contest'...)

The F11 Test Days happened in March 2009, the F12 Test Days in September 2009, and the F13 last week; these are pretty comparable points in the respective cycles.

In terms of participation, we had the largest number of testers for F11, with the nouveau number accounting for most of that; I suspect this is because nouveau was very new and shiny in F11 and impossible to use on most distros, so people were very interested in trying it out for the first time. F12 had the fewest tests run, and F13 pretty much splits the difference.

Since I'm getting up a head of steam, let's look at fixes!

f11 nouveau: 42 bugs, 4 open, 8 closeddupe, 24 closedfixed, 6 closedunfixed - 70.59% f12 nouveau: 34 bugs, 11 open, 8 closeddupe, 14 closedfixed, 1 closedunfixed - 53.85%

f11 radeon: 46 bugs, 14 open, 10 closeddupe, 19 closedfixed, 3 closedunfixed - 52.78% f12 radeon: 81 bugs, 19 open, 32 closeddupe, 28 closedfixed, 2 closedunfixed - 57.14%

f11 intel: 21 bugs, 7 open, 1 closeddupe, 12 closedfixed, 1 closedunfixed - 60% f12 intel: 31 bugs, 7 open, 12 closeddupe, 12 closedfixed, 0 closedunfixed - 63.16%

I counted CANTFIX, WONTFIX and INSUFFICIENT_DATA as 'unfixed', ERRATA, RAWHIDE, CURRENTRELEASE and NEXTRELEASE as 'fixed'. NOTABUG I lumped in with DUPLICATE as the 'closeddupe' number (these are reports that should be discarded from consideration entirely). The percentage is calculated as:

closedfixed / (bugs - closeddupe) * 100

i.e. it roughly indicates the percentage of genuine unique bugs reported that have been fixed so far. These numbers are pretty close, both across drivers and across releases; we've fixed just over half the bugs reported. I think the outlying high nouveau result is probably a consequence of 'low-hanging fruit' - the driver was in a pretty initial state at that point, so the bugs exposed are likely to have been, on the whole, easier to fix. Obviously I've left F13 out as the maintainers have had only half a week to work on the bugs!

Thanks very much to all testers, and to the wonderful Fedora X.org developers and triagers:

Adam Jackson Dave Airlie Jerome Glisse Ben Skeggs Matej Cepl François Cami Chris Campbell

for helping to organize the events, set up the test cases, man the IRC channel and triage - and of course fix! - all the bugs.

The SmartQ V7 I wrote about arrived this morning.

So, first impressions: yes, it really really is the Anti-iPad. The whole thing just exudes rough edges.

It boots to a triple-boot selector (Windows CE, Android, Linux) you can't use the touch screen on. First I booted up Android, and poked about a bit. It's, well, Android. There's a rather gigantic deal-breaker, though: the wireless doesn't work. It 'turns on' one out of every two or three tries, but fails trying to scan for networks, then when you go back to the settings menu it's shown as off again. I tried several times across three boots, never got a connection. I've found several threads on the various forums where the SmartQ devices are discussed mentioning similar problems; no-one seems to have any idea how to fix it. I can pair with my phone with Bluetooth, but couldn't figure a way to use the phone's internet connection over BT.

So, Android is basically useless, at least until they fix that. So I've been mostly using the "Linux" option. This is actually a fairly customized install of Ubuntu 9.10 for ARM. It runs LXDE as the desktop, with a hacked-up gigantic-icons 'quick launch' bar at the bottom of the desktop, and a range of fairly well-chosen apps (Midori for browsing, Claws for email, FBReader for ebook stuff, etc).

In contrast to Android, the wireless works right out of the box, using good old NetworkManager. I couldn't get Bluetooth tethering to fly, though; they use a rather odd setup for this. They have Blueman for controlling Bluetooth, and you're supposed to use Blueman to set up a DUN link with the phone and then run gnome-ppp which somehow transforms it into an actual connection. I got this to work once in ten tries, for about five minutes. So I've given up and am just using my phone's wifi router functionality, which eats battery life but works simply. Hopefully a future version of the Linux implementation (they do release updates fairly frequently) will come with the newer gnome-bluetooth and NetworkManager builds that allow much smoother Bluetooth tethering.

In use, it's...well, endearingly clunky, I guess. It is very clearly essentially a desktop Linux environment squished down to a 7", 800x600 display. Windows render off the screen, and things chug along since it's not exactly stuffed to the brim with processing power. It's a lot nicer with a stylus than a finger; the on-screen keyboard works okay but tends to pop up over whatever it is you're typing into, so you have to type blind then close it to see if you actually managed to type what you were aiming for.

The build quality is...okay. You're not going to mistake it for a Sony, and it's all plastic, but nothing is loose or jiggly and all the bits fit together fine. The touchscreen showed up pretty well calibrated. The buttons feel cheap but solid. It's around the higher end of what you'd expect for the money.

It's certainly capable of browsing the web fine, which is one major thing I want it for. Book reading is pretty nice: it uses FBReader, and has sensible shortcut keys (to save anyone who buys one five minutes, the 'menu' button toggles full screen mode, and the 'left' and 'right' buttons flip through pages; there's a button on the toolbar which does rotation). Only drawback is the fonts are noticeably more jaggy than my Sony Reader - might see if I can tweak the font settings somewhere.

I did an initial test of video playback; it comes with accelerated builds of VLC and (allegedly) mplayer built-in. Testing with a 720p video with soft subtitles, first attempt failed; more jankiness! You have to reboot and go to a special boot option menu which lets you adjust the memory configuration; the default option provides as much memory as possible for normal operation, but there are two settings which devote extra memory to (I guess) the GPU to allow hi-def video playback. With the middle setting (188MB RAM available for normal use) it could play the video pretty well in vlc, though the subtitles weren't showing up right. mplayer failed to run due to a missing libvorbisdec.so.1.

On first attempt email is kind of a no-go for me; I think it just doesn't have the power to cope with my ridiculous mountain o' mail (there's 100,000 messages or so on my personal server). Claws isn't a great experience on a 7" screen either. I'd like to try a more phone-y app like Modest, but it segfaults at run when I try installing it.

At this point I've decided to install the latest Linux build for the device - it came with build 5.4, 5.5 is now available - and see how that flies.

All-in-all there's a lot of rough edges, but I'm having fun playing with it, and it could turn out to be a net win over my Sony Reader for simple book reading + web browsing. Obviously the openness of the system leaves a whole bunch of possibilities available too, which is great. It'd be nice to have a more working Android build in future, I'll keep my eye on that. We'll see how useful the thing turns out to be over the next couple of months...

Just a reminder to everyone that we're still right in the middle of Graphics Test Week. The NVIDIA Test Day yesterday went very well, and of course you can still add results to that page if you didn't get around to testing yet. Today is the ATI/AMD Test Day, so if your graphics card is from ATI/AMD, please do come join us in #fedora-test-day on Freenode IRC and get your test results into the page. And looming tomorrow, as well as what will no doubt be an epic beatdown of the L.A. Kings by the Stanley Cup-bound Vancouver Canucks, is Intel graphics Test Day. Be there or else!

As racing has the Monaco GP, tennis has Wimbledon, and soccer has the World Cup, so the Test Day schedule has its crowning event: yes, it's Graphics Test Week again!

As with Fedora 12, we're smooshing all the graphics card Test Days into one week to save space on the schedule and make everything feel that much more momentous. So, Tuesday April 13th will be NVIDIA (nouveau) Test Day, Wednesday April 14th will be ATI/AMD (radeon) Test Day, and Thursday April 15th will be Intel graphics Test Day. As always, we need your feedback to know where we're at for the Fedora 13 cycle and fix as many critical bugs ahead of release as we can. Again as always, it's not a disaster if you miss the day - you can do the testing before or after the day, and we'll still be able to use your results; the day is just when you can be sure someone will be around on IRC to help with the testing and discuss the results. And finally, again as always, there's no need to have an unstable Fedora installation to do the testing: you can use a live CD if you don't want to install Fedora 13 or Rawhide.

Significant changes to graphics support for Fedora 13 include very experimental 3D support for NVIDIA cards, and improvements to the still-experimental 3D support for recent AMD/ATI cards. Please do come out and help us with the testing this week! You can do all the testing just by following the Wiki instructions, but there will also be QA team members or developers present in #fedora-test-day on Freenode IRC throughout the day to help with the testing and discuss the results (and possibly even fix some of the bugs in real time). If you're not sure how to use IRC, read this page.

It's shiny thing day again!

With my tax refund burning a hole in my pocket, I couldn't resist buying one of these. It's a 7" tablet which triple-boots Android, Ubuntu and Windows CE. All for less than the cost of my Sony reader.

If you read reviews of this thing, they're fairly negative, based on the fact it's a crazy-ass hackjob thrown together in the back streets of China, with odd hardware and more quirks than you can shake a stick at, that doesn't know what the hell OS it wants to run when it grows up. It in absolutely no way resembles a smooth, polished product.

Anyone who's ever paid any attention to this blog should already have figured out that's why I bought it. =) Crazy hack job which requires forum-researched tweaks, firmware flashes and Linux knowledge to do anything useful with? Sounds right up my street.

If the thing actually turns out to be practically useful it's great, but if not, hey, I'll probably have $250 worth of what I consider 'fun' before I send it off to someone as Fedora ARM research material. It's win-win, baby.

Good thing I figured out how to un-DRM my ebooks...

We saw 'How To Train Your Dragon' (though Dreamworks seems to have had a late change of heart, and spent most of the promo period calling it 'Dragons'...odd) this weekend. And, well, it's really great. It's ultimately just a fairly sappy cliched aimed-at-kids movie on fairly well-worn plot lines, but a few things about it made it stand out for me.

One, it doesn't try far too hard, like most Dreamworks movies do. You could tell it was based on a book, and a fairly good one at that; there was a good depth of material there, for such an essentially simple plot. It didn't feel at all forced.

Two, it may be cliched, but cliches exist for a good reason: the heroes-ultimately-triumph-over-nailbiting-adversity trope is as powerful as ever, when done properly, and this movie does it very well.

Three, it avoided many of the more annoying bear traps of the genre. It's quite a gentle movie...it sort of follows the 'misunderstood genius kid' conventions, but no-one really hates the misunderstood genius kid. There isn't an obvious nasty bully for the misunderstood genius kid to triumph over. It's done more quietly than that, and you can engage more with the characters because of it. The dragons don't talk, and aren't treated as humans-in-stupid-costumes; they're clearly animals, and they respond as animals. All the way through, it avoids getting stuff wrong that it could have got really wrong.

But most importantly, four, the thing I really loved about it is that it manages, in a subtle, gentle and non-preachy way, to emphasize the virtues of research and invention. Which is really pretty clever for an 80 minute animated kid flick. It doesn't sound very good if I say it has a couple of really neat, short, montages of what is, essentially, observational biology, but it does. And they are neat, and they work. Genius!

Okay, I lied. The fifth thing is the most important. It has Craig Ferguson in it, and everyone loves Craig Ferguson. Not only that, but it has Craig Ferguson doing a silly comedy Scottish accent...even though he actually is Scottish.

If you have kids, please, take them to see this movie. It'll be good for them, and you'll probably like it too.