11am: Arrive at work, check out crack pipe from inventory 11:05am - noon: Read online forums, cackle at victims; crack pipe Noon - 1pm: Read latest standards documents; write code that is in technical compliance but to any sane observer appears screamingly inept, baroque, buggy, unusable and downright dangerous 1pm - 2pm: Lunch with friend from International Tax Code Writers' Union; compare notes 2pm - 3pm: Review usability testing results; remove all discovered usability 3pm - 3:30pm: Bonghits 3:30pm - 4:00pm: Reading - "Transparency, The Apple Way (S. Jobs)" 4:00pm - 4:30pm: Notice latest production firmware code does not include enough potential bricking bugs; run random bug generator 4:30pm - 5:00pm: Notice company has minor hardware revision upcoming; write entirely new firmware implementation for it for no apparent reason 5:00pm: Home, with a warm fuzzy feeling of achievement 5:30pm - 11:30pm: Tease dog by pretending to throw ball 11:35pm: Watch Leno

Thanks to Daniel Siegel for the link to this one.

I have come across some truly crazy bugs in my time - buy me a beer at a conference and I'll tell you about them - but I don't think anything tops Trey Harris' Case of the 500 Mile Email. That's amazing.

As I mentioned, I spent the weekend at LinuxFest Northwest, a great conference I've been to three times now.

Bryan Lunduke does a recurring talk there which is called "Why Linux Sucks" or something like it. It's a great talk, where Bryan gives his tongue-in-cheek opinion on what's holding back desktop (and, more recently, mobile) Linux adoption. There's a video of this year's talk.

Bryan's awesome, and we get along great. I love his talks (in the last couple of years he's started following the "Why Linux Sucks" talk with a "Why Linux Rocks" talk which uses almost the exact same slide deck, which is an awesome idea). But I think he's wrong on one point he brings up. It's hard to do a good job of explaining why concisely during the talk - you can watch me doing a bad job of it in the video! - because it's a complex issue that's hard to distil. So I thought I'd write it down instead.

The problem Bryan identifies affects third parties providing Linux applications directly to users: Bryan trying to provide his games to users of different distributions, or Google trying to provide Chrome, or Mozilla trying to provide Firefox, and so on and so forth.

If you're one of those third parties, you can put your application in a package, or you can put it in a tarball.

If you put it in a package and provide a repository, your users can take advantage of the features of package management. Your app will show up in their package management applications, it will be updated when they do a system update, and a few other things. But there's a problem: different distributions use different package formats. So if you just do one package (and repository), you won't be covering all your potential users. If you do RPM and DEB you'll cover 90+% of them, but there are still a few who'll be left out.

If you put it in a tarball, you can just make one, and give it to users of all distributions. They'll all be able to extract your app and run it. But it won't show up in their package manager. You'll have to tell them to download a new tarball, or write your own update mechanism.

Bryan wants for third parties to be able to get all the neat stuff that comes with using a packaging format, without the inconvenience of doing multiple builds.

If distributions all used the same packaging format, would Bryan's goal be achieved? Absolutely. Is it a worthwhile goal? Sure. I don't think it'd change the world, but we agree it'd be a benefit.

So Bryan's right? I'm an idiot? Well...not so fast there!

Switching package formats for a distribution is a huge pile of work. I can explain why if anyone needs me to, but for now I'm going to assume you're willing to take it on trust.

If all distributions used the same package format, that wouldn't help them directly at all. A lot of people believe that if, say, Fedora, OpenSUSE and Ubuntu all used the same package format, you could just mix and match packages between them, and each distro wouldn't have to package everything separately.

This is not true, we can't ever make it true, and we don't want it to be true. I'll try to explain why as quickly as I can: distributions are very different, and they all are strongly committed to using shared resources.

When you get Chrome from Google, you get a static build: it uses very little of the shared resources the distribution provides, stuff that's present and compatible on virtually any distro.

When you download a package from your distro vendor, it's not like that. Distros use dynamic builds: distro packages use all the shared resources they can. Just take it on trust that the benefits are huge and distributions will never start using static linking outside of the cases where it's unavoidable (ask me for details if you want). Distros differ in terms of the shared resources they include, and this isn't just being ornery, it's a key part of what differentiates distributions from each other, and why we have them at all. Fedora 18 has openssl 1.0.1e. Ubuntu has 1.0.1c. RHEL 6 has 1.0.0. Debian stable has 0.9.8o. This is because Fedora is bleeding edge, Ubuntu is a bit more conservative, RHEL 6 is a lot more conservative, and Debian stable is even more so. We couldn't all get together and 'agree to compromise on 1.0.0'. Then none of those distributions except RHEL would be serving the needs of its users.

Multiply that by the thousands of packages in a distribution. You can't take a Fedora 18 package and install it on RHEL 6, even though they are both RPM distributions, because the package expects stuff from Fedora 18 that just isn't in RHEL 6.

So we've got a cost/benefit. The benefit? It's there. The cost? It's huge, and it falls on groups that don't directly benefit at all. This sucks. But fortunately, we don't need to pay that cost!

We don't need all the distributions to agree on a common package format for their packages so third parties can provide applications with most of the benefits of package management. All we need is for there to be a package management framework that third parties can rely on to be present on all distributions. It doesn't matter at all whether the distribution packages use it or not.

That's a much easier problem to solve. All we'd need to do is agree to all provide support for one existing package format out of the box. (Sidebar: LSB already actually tries this. It requires RPM.) That's one big bunfight at a conference and maybe like a week or so of work. No big deal. If Bryan pushed for this instead of saying 'all distributions should use the same package format!', I'd have no disagreement with him.

You can stop reading here if you like! But if you're thinking 'hey, waitaminute'...

To pre-emptively address one objection: what if a third party wants to provide a package that depends on something in the core distribution?

Bryan's idea would go a bit further to addressing that than mine would. But it's not so important, Bryan's idea still doesn't totally solve it, and you can modify mine to solve it quite easily.

It's not so important because most significant third party providers just want to make their package as independent as possible. They don't want to worry about making sure their app works with all the possible versions of the shared resources they want to use that are shipped by the various distributions. They usually just link almost everything statically. Here are the requirements of Google's Chrome RPM, for instance:

libatk-1.0.so.0()(64bit) libc.so.6(GLIBC_2.11)(64bit) libcurl.so.4()(64bit) libgconf-2.so.4()(64bit) libnss3.so(NSS_3.12.3)(64bit) libbz2.so.1()(64bit) libXss.so.1()(64bit) libXcomposite.so.1()(64bit) libXfixes.so.3()(64bit) wget xdg-utils zlib

Honestly, you really don't need to specify any of those. If someone's running a Linux distribution with a desktop (which they are if they want to install Chrome), it's about 99 to 1 they have all of that installed.

Bryan's idea doesn't fully address this requirement because distributions don't all agree on what different packages should be called, or how library dependencies should be written, etc etc etc. It's slightly more likely that we could all agree on that than that we could all switch to one package format, but it's still a hell of a long shot. Even if we all used the same package format, you couldn't just write "Requires: foo" and be done. One of the distros probably calls it "libfoo". You'd still have problems.

And you could pretty easily achieve this with my idea, too. Better, we don't have to do it all at once. We could just get the format in place first. If that was a success, then 'I want to be able to specify some dependencies!' is an obvious enhancement request, and now we're building on an existing idea, not just throwing impractical proposals around.

Maybe we can't get all the distros to agree on the names of absolutely all their packages, but we could get them all to agree to have their GTK+ 3.0 package provide gtk+-3.0 under the shared packaging system. The names could still differ under the native packaging systems - it wouldn't matter. But it's plausible to see us agreeing on a set of commonly-required core components, and doing the work to have the distro packages express those provides in the shared package manager as well as their native package manager, using an agreed nomenclature. And it could be incremental - we could just start by doing 50 packages, or 10, or just one; however many we could agree on. And then build it out as we went along. And none of this would in any way disturb the functioning of the distro's native package system and repositories.

I'm writing from LinuxFest Northwest once more - right now I'm watching Jesse Keating present on git. The conference is really buzzing so far this year; I've been spending most of my time manning the Fedora booth, and the swag is disappearing like crazy and we've had people stacked three deep at times. It's always a good conference. Come find me and say hi if you're here! I'll be at the Fedora booth a lot both today and tomorrow. We have been signing people up for OpenShift accounts at a rapid pace: if you stop by and prove you have an OpenShift account, we'll give you a USB key that is ALSO a bottle opener. Or possibly a bottle opener that is ALSO a USB key. At least until we run out, which is likely to be soon.

Of course, being at LFNW means yesterday I travelled to LFNW - it's just a train ride down from Vancouver. Being a giant idiot, I decided that 'five hours before the train to LFNW leaves' would be a great time to upgrade the CPU and memory in my husband's system. Yeah...turns out, not so much. Windows managed once more to stun me with its incompetence: after an hour of hardware wrangling I had everything hooked up and booting, but Windows was just stuck in a boot loop. It turns out that for some insane reason, a Windows install is kind of tied to the CPU: if you upgrade the CPU to one that's sufficiently different (though still the same architecture!), Windows stops booting.

I mean....why. WHY?!

It is apparently possible to escape from this situation, but it was now 30 minutes before the train to LFNW left, so I thought it was possibly not the best moment to be figuring out Windows' system recovery options. So followed a very hasty 30 minutes of further hardware wrangling, getting the old CPU and RAM back in. So I wasted an entire stressful afternoon to ultimately put everything back exactly the way it was before and rush to catch my train. D'oh.

Yup, it's that time again - one of the bigger weeks of the Test Day cycle, as Graphics Test Week lands once more.

Tomorrow, Tuesday 2013-04-23, is Intel graphics Test Day. Wednesday 2013-04-24 will be Nouveau Test Day. And Thursday 2013-04-25 will be Radeon Test Day.

As always, we'll be looking to test out the widest possible range of hardware and see how well it works with the very up-to-date graphics stacks in Fedora 19. As Fedora uses very recent builds of the relevant components and sends all its work upstream, contributing to these Test Days can help out all other distributions, not just Fedora - so please, even if you're not a Fedora user, consider coming and contributing your testing! We provide comprehensive instructions and live images for testing, so you won't need to replace your current distribution or do a permanent installation of Fedora at all if you don't want to. You can easily write a Fedora live image to a USB stick, so you don't even have to waste a DVD.

We always want to get as much data as we can in these events, so please, if you have a few minutes, help us out and perform the tests for your system(s). If you can't make the correct date for your hardware, no problems - you can file results early or late and we'll still be able to use them. It's also fine to come to the IRC channel on the 'wrong day' and ask questions - we'll have folks in the channel all week who will answer your questions if they can. The testing is very easy, and if you don't have time to run through all the test cases, partial results are still very useful - if all you have time to do is boot the live image and check whether the desktop appears on your system, even that is useful.

As always, the full instructions and live images are on the Wiki pages: Intel, Nouveau, Radeon. Fedora QA team members and graphics developers will be hanging out in the #fedora-test-day channel on Freenode IRC to help out with testing and debugging any problems you come across, so please come join us there if you're taking part! If you're not sure what IRC is or how to use it, we have instructions here, and you can also simply click here to join the channel through a Web front end - all you need to know is that IRC is a chat system.

Thought I'd write an on-topic blog post, for a change!

Sadly, we had our first Fedora 19 delay last week. I actually was trying pretty hard to get this to be the first release where we didn't slip at all, but alas, this was not to be.

The good news is this is nothing like the Fedora 18 situation. In F18, when we hit the first go/no-go for Alpha we were barely within shouting distance of having anything releasable, and Beta was worse: we didn't just have a few stray bugs, we were still writing bits of the installer.

What's holding up Fedora 19 Alpha, in contrast, is two bugs in UEFI installation, and that's it. (Note for the haters: none of the bugs has anything to do with Secure Boot). The installer is in fine shape, except for an issue in the custom partitioning screen which we'll try and slip a fix in for. All the code that was meant to be written by now is actually written, it's all working pretty well, and most of the functionality of the installer is pretty solid. There have been a ton of UI improvements since Fedora 18 based on both online feedback and real-world usability testing and observation, as well.

So it sucks that we had to slip, but it's a much different situation from Fedora 18, and it's been a lot lower stress - we're not running around trying to keep tabs on 15 bugs and 5 features that aren't written yet, right now we're really just waiting on upstream review of a patch for the last UEFI issue (the fix will need to go into the upstream kernel, and we won't put it in Fedora until it's in an approvable state for upstream merging).

We made some fairly significant changes to the release validation process prior to the Fedora 19 cycle, and we've been happy with how they're working out so far. At FUDCon Lawrence, the QA members present came up with a plan to revise the "nice-to-have" process by which we track fixes that we want to take through the Alpha, Beta and Final freezes. That proposal was sent to the mailing list, where in turn, a lot of the group members who weren't at FUDCon contributed improvements to it. We rolled out the changes to what is now called the freeze exception process - because, you know, it's for freeze exceptions! - ahead of the F19 Alpha validation process, and it's been working out well so far. It really boils down to renaming "nice-to-have" to "freeze exception", but there are some devils in the details, and it makes what was a somewhat poorly-understood process much more understandable.

I drafted up some substantial revisions to the layout and content of the release criteria just ahead of the Alpha release. The changes have been put into practice for the Alpha release criteria (compare with the F18 Alpha criteria to see the changes), and will go into place for the Beta and Final criteria before we reach those milestones. The idea is to have a shorter 'main' text for each criterion with details and 'commentary' as expandable extra paragraphs, and to lay out the criteria better so it's easier to read the page and to refer to specific criteria. So far the changes seem to have been integrated into the process smoothly enough.

Finally, we made some tweaks to the blocker bug process and blocker review meeting process to try and expedite blocker (and freeze exception) review a bit. We introduced the concept of automatic blockers to try and cut down a bit on unnecessary review of issues that are very obviously blockers, and tried to set things up so blocker review meetings don't run on forever. Again, those changes seem to be working out well.

So I'm feeling good about the Fedora 19 cycle so far! I'm hopeful there'll be very few (or no) further delays after this first one, and we'll wind up with a very solid release, with significant improvements to the new installer.

The Meme Hustler is the best thing I've read all year, and if you haven't read it yet, you should. It's a hatchet job on Tim O'Reilly, basically, but it's a really good one, and it winds up being much more profound than that. Really, just go read it right now.

From the Department of Random Pontification:

What is it with the cancer of "we" which has spread through so-called 'serious' journalism in recent years?

It really irks me. It's prevalent in the mainstream online and print media, and in most 'serious' media sites in various niches - entertainment, technology, whatever. People who write opinion pieces apparently all got a memo a decade or so back to talk about "we" all the time.

They don't write "I think some people use Facebook too much", they write "We all use Facebook too much". They don't write "Is your email box overflowing?", they write "We all suffer from overflowing mailboxes". And so on.

I guess the idea is to sound all inclusive and not as if you're condescending to the reader, but for me at least it falls flat on its face, because half the time it feels like I'm being accused of something. I don't use Facebook too much, thanks. Maybe you do. Maybe some other people do, I don't know. But writing 'we' seems to be a presumption too far. Ditto with overflowing mailboxes, social anxiety or whatever else it is 'we' are apparently all suffering from this week, in the opinion of whatever editorial writer I happen to be reading at the time.

Opinion piece writers of the world, 'we' don't all have your problems. If you want to write about your own problems, fine. If you want to state that other people have them, find some other people and define that set accurately. Don't co-opt the entire rest of the world as fellow sufferers of whatever affliction you're dealing with...

And now, for something completely different, may I present you with:

Mike Krahulik shouting my name while chasing a duck.

Kickstarter: sometimes, it's money well spent.

As we work towards releasing the Fedora 19 Alpha (due in a couple of weeks), the Fedora 19 Test Days continue apace. Next up, tomorrow - 2013-04-04 - is printing Test Day. The goal is to check that the printing stack and user-facing tools are all in good working order for Fedora 19. Printing is something most of us still have to do from time to time, and it's easy to test from a live image, so this is an ideal Test Day for most anyone to get involved in - the testing is easy and there's no need to risk any permanent changes to your system. If all you have time to do is boot up a live image and test if your printer works, that's great!

So please, check out the instructions on the Wiki page and help out tomorrow if you have a bit of spare time. You can join us in #fedora-test-day on Freenode IRC to get help or discuss any problems you find. If you’re not sure how to use IRC, we have some instructions here, or you can just click here to join through a Web front end.