Okay, so here's the deal - what I know about snowboarding wouldn't fill the back of a postage stamp, but even I can tell when fifteen guys are working very very hard for a silver medal while the other would win the gold with his eyes closed and one leg tied behind his back. That Shaun White guy is just unbelievable.
It's Test Day time again!
This Thursday, 2010-02-18, will be Color Management Test Day. There's some exciting new color management features in Fedora 13. That is to say, there are color management features in Fedora 13! We've never had any real color management in Fedora before, so this is great news for photographers and designers in particular - but everybody, really.
The good news is testing for this Test Day is very easy - anyone with a monitor can do most of the testing. A scanner, printer, webcam or colorimeter let you do some other tests. You don't need a Rawhide installation to do the testing, just a nightly live image will do fine, and the testing process is fully documented and won't take more than a few minutes. So come out and help us test! Even if you don't use Fedora, you can test very easily with a live image, and this is one of those features that's popping up in Fedora first but will soon appear in all distributions (as it'll be part of GNOME itself), so you'll be helping your own distribution by testing.
Thanks a lot to Jaap A. Haitsma for alerting me to WPTouch, a very neat plugin for WordPress which automatically presents a mobile-friendly appearance when it detects a mobile browser user agent (and you can customize the user agent list). So now when you visit this blog with a mobile device you should get a much nicer view than the shrunken-desktop-view. Neat stuff!
So, this is insane:
That's Spring. What's Spring? Well, it's a fairly neat open source RTS framework that started out as a Total Annihilation clone, but more to the point, it's a pretty complex 3D game. What's cool about the picture? Well, it's in the renderer info in the console (which you probably can't quite make out, never mind). Yup, that's Spring...running on Nouveau!
Huge kudos to the whole nouveau team for this. Nouveau's 3D support recently became available in Rawhide / Fedora 13 with an update to the mesa-dri-drivers-experimental package. I was impressed when it ran Compiz, really impressed when it ran Neverball and Foobillard, but running Spring is nuts. Doesn't seem to manage gnome-shell yet, but I'm sure they can fix that. I admit I never expected to see things working like that in such a time frame. Obviously it's heavily hardware dependent, it doesn't run super-fast (looked like about 20-25fps, just by eyeballing it, on my 9400 GT) and I haven't stressed it much yet so it may be crashy, but still, that's incredible stuff.
edit: it also runs Quake 3. Quake fricking 3!
It seems early as always, but we're just about to start up the Fedora 13 Testing Machine, which will roll on right up to the final release in May. The Alpha release is due early next month, and this week we start off by testing the first Alpha 'test compose', which will arrive on Thursday 2010-02-11. We have some changes to the validation testing we'll be doing for all pre-releases and pre-release candidates this time around.
The installation validation testing hasn't changed greatly, but the test cases have been slightly reorganized to reflect the new release criteria, and also general changes in the Fedora world since the list was drawn up. A few have been removed and the test priorities have been reorganized to be based on the release for which the test must pass (Alpha, Beta or Final).
A bigger change is the introduction of desktop validation testing. As part of the new release criteria, we added some criteria which are not based on installation but on the functioning of the installed system. We've gathered up most of these into desktop validation testing, which will take place alongside installation validation testing. So alongside the installation validation testing results page for the test compose, there's now a desktop validation testing results page. You can see the list of tests that will be performed there, and there will be a similar page created for each testing stage before the final release of Fedora 13. Columns are included for all major desktops, but only the default desktop results (GNOME) are able to block the releases, for now.
I'm hoping this testing goes well and helps us ensure that future releases have a desktop that works on a basic level out of the box. Please do pitch in and contribute tests to fill out the results page! I'd especially love to see results from all the non-default desktops in the matrix, KDE / Xfce / LXDE folks ;)
Wow, it's gotta suck to be President Obama right now. You've got the conservatives blasting you for your evil schemes to turn the health of poor innocent Americans over to shadowy gub'mint Death Panels (as opposed to, y'know, shadowy insurance company Death Panels), while the geeks excoriate you for your dastardly plans to stop wasting gazillions of dollars of public money on sending some square-jaws to stand on the Moon and wave a flag (again). Fun times!
(It's always interesting to note how many people who are otherwise hard-boiled 'fiscal conservatives' are unreservedly in favour of any massive government expenditure which ultimately goes 'boom' in a really big way. If I were a physicist in America I'd be figuring out a way to make a particle accelerator that's jet-propelled right now. If the design mockups show a jet of flame roughly the size of New Jersey firing off out of an exhaust vent somewhere, it'll have all of Congress clamouring to sign off on it...)
It's that time again: blocker bug review meeting time! Yes, yes. Already. Tomorrow is the first blocker bug review meeting for Fedora 13 Alpha: that is, 2010-02-05 at 15:00 UTC in #fedora-bugzappers.
Here are the current bugs listed as blocking the Alpha release. We'll be discussing all of these. Have an issue you'd like to propose as an F13 release blocker? Please consider the Fedora 13 Alpha Release Criteria when escalating an issue.
The aim for the Release Criteria for F13 is for our criteria to match up with our 'gut feelings', so if you see an issue that you think should be a blocker but doesn't meet the criteria, please add it as a blocker and mention at the meeting that the criteria don't cover it. Thanks!
To promote a bug for consideration as a blocker, simply mark it as blocking the bug 'F13Alpha'. You can also already mark bugs as blocking the Beta or Final release, if appropriate, by using 'F13Beta' and 'F13Blocker' respectively.
Hope to see everyone at the meeting tomorrow!
In a break from our regularly-scheduled programming of posts about screwing around with miscellaneous technological widgets, I bring you some Fedora news!
We're getting the Fedora 13 Test Day cycle under way. This Thursday - 2010/02/04 - will be the NFSv4 Test Day. The big NFS change for Fedora 13 is that NFSv4 is now the default (rather than NFSv3), so the Test Day will aim to ensure that all existing NFS configurations work as smoothly as possible in this brave new world.
There will, as always, be live CDs available for testing. As an added bonus, you can even do testing on Fedora 12 with just a few easy changes that are documented on the Test Day page. There are pre-defined test cases to run through, and we would also welcome testing on just about any NFS configuration. There will not be cake, not unless you're really, really lucky - but there's just about everything else!
Please do come out to the Test Day to help us test this important new Fedora 13 feature. It will be held all day in #fedora-test-day on IRC. See this page if you're not sure how to use IRC - or you can use WebIRC just by clicking this link! Ah, the wonders of science.
So, as I mentioned, there is a usable Android port for my phone - the Tilt 2 variant of the Touch Pro 2 (codenamed Rhodium). Now I have negotiated all the Google fails surrounding making an Android setup vaguely useful, I may use it along with WM for a while, until the port is better. One problem with that is that the keyboard mapping on current Android builds for the Tilt 2 is completely wrong.
Most Android porting work is being done by developers with Touch Pros, for a start, so the keyboard mappings are set up for that phone - rather than the TP2 - out of the box. If you have a TP2 it's fairly similar so most keys are fine, just a few are wrong. For the Tilt 2, though, AT&T got HTC to totally rework the keyboard. A Touch Pro 2 has a number row across the top; on the Tilt 2 those are symbol keys, and numbers are alternate mappings for three of those keys and seven of the letter keys, in a numeric keypad layout. So what you get when typing on a Tilt 2 in Android doesn't at all match what's printed on the keys. There are some other differences in the mapping too, with the effect of rendering some rather important characters - like / - completely inaccessible on the hardware keyboard by default.
So, I decided to actually do something useful rather than just playing with other people's work, and fix it. Rather to my surprise, I was successful. I set up a key mapping configuration that makes the important functions of the Tilt 2 keyboard work as they should. Due to some issues with the 'upstream' kernel work that I won't bore you with, I haven't quite polished it off yet, so some less important things don't work right; once the kernel stuff is worked out (once some Rhodium-specific fixes that one of the kernel guys has lands in the main tree and there's a new build I can work off) I'll polish it up so everything's 100% and send it up to the XDAndroid people. Yay - I feel useful! I'm also going to do a TP2 map to fix the TP2 keys that don't work right, if someone with a TP2 provides me with the necessary data.