I'm almost ashamed to admit that last year, I think I only read (as in completely, cover to cover) 3 or 4 books. This year doesn't seem to be going much better either. I'm still slowly making my way through my first of the year. The problem isn't that I'm a slow reader. My problem is one of choice. I buy a book, start reading it, and when I'm halfway through, for whatever reason, I'll end up with another new book, and start reading that one, and the cycle repeats. I'm great at starting books, awful at finishing them. I think I must have started reading about 20-30 books last year alone. I seem to only really get through books when I'm traveling. The fact that I don't have a bookcase full of options with me confines me to one or two choices. This is the reason that devices like the kindle, (or any other e-book reader for that matter) are a really bad idea for me. When overwhelmed with choice, my indecision consumes me. (Seriously, you should see me fail at choosing a lunch option when in a new city surrounded by restaurants. Even the infamous google cafeteria was total overload for me. I think if I worked there, my indecision would actually lead to me starving to death before I made a lunch choice).

Last November, whilst in Portland,OR I picked up a copy of The soul of a new machine. It's a book I've been meaning to read for years, after countless recommendations from friends. Same old story though, I'm dragging my heels getting through it. It's not that it isn't an interesting book. It's really interesting to me how many parallels there are in the story to things that are happening/have happened at Red Hat.

I think I'm about halfway through it. 7 Months. Perhaps I need to travel more.

For an OS that apparently "just works", I seem to encounter a remarkable amount of fail.
Some investigation reveals all manner of disasters in syslog..

kernel[0]: IOAudioStream[0x4634100]::clipIfNecessary() - adjusting clipped position to (d0b9d,3fd9)
kernel[0]: IOAudioStream[0x4634100]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (d0b2f,3ff9)->(d0b9f,4b).
The best part about this fail is that it does it even when no audio is playing. I just need an app that plays audio to be open.
Result: A gazillion of these in the logs.

usbmuxd[104]: MuxTCPSendRST StartWrite failed: 0xffffffff
usbmuxd[104]: MuxInterfacev1Receive Dropping packet. Received 26036, expected -769822944 bytes
lol whut?

kernel[0]: AppleYukon2: 00000000,00000001 sk98osx sky2 - - sk98osx_sky2::replaceOrCopyPacket tried N times
Good job. Please try n+1 times.

This is just from todays log, and just the kernel messages. The spew from userspace freaking out about this that and everything is even worse.

But at least it looks pretty whilst it's failing.

Comcast's DVR is the only device I've ever owned that seems to consistently get worse with every firmware update. From the removal of useful shortcuts, to putting invasive advertising in the program guide reducing screen space for useful stuff (like program info). The last two updates have really got under my skin though.

After playing back a recorded program, it used to pop up a dialog asking if you wanted to delete it. This no longer happens. Instead you stare at a frozen image. When you press 'stop' the dialog appears (it also appears after 15 seconds of staring at the frozen screen). According to forum posts I found somewhere, this 'feature' was added because some customers (read as 'morons') felt "panicked" and "rushed" into making a decision. Comcasts official line is that this feature was added so that people could rewind from the end and watch the last scene of a program again. Sounds great. The best part is, this was always possible. Even when the dialog was onscreen.

The latest "feature" that drives me up the wall: The DVR box has an LCD on the front displaying the time, or the current station being watched. When in standby mode, it shows the time. This is really handy, it means I don't need another clock in the room. Or at least that was the case until the last firmware update. Now, after a period of inactivity (ie, whilst in standby for a while), the LCD powers off. I'd like to think there's some benefit to this, like saving power. However, due to comcasts ineptitude, the DVR box actually uses the same amount of power in standby mode as it does when powered up. Winning. Net result: I no longer get to put my DVR in standby mode. (Not that it ever did anything anyway).

Every time this gets under my skin, I get renewed enthusiasm to get mythtv set up. Then I remember what a pain in the ass that was the last time.

I thought this was absurd when I saw it. Given the ubiquity of 802.11 signals pretty much everywhere (Even at my parents place in the boonies of the welsh valleys I noticed multiple APs), it seems kind of pointless. The sillyness doesn't stop there however. Those with a penchant for looking ridiculous can now also get some matching shoes.

FAIL.

wifi-detecting clothing is the hypercolor of this decade.

I went to lunch at one of the towns 49 all-quite-the-samey sushi restaurants that I'd not tried yet. I was seated next to someone who seemed to be some kind of dial-a-psychic. She had tarot cards all over the table, and appeared to be giving a 'reading' over the phone whilst she gobbled down maki. She had a companion who was also on the phone during the entire meal. I don't think they spoke a word to each other. I'm not sure if she was also a psychic. The whole experience was very surreal.

Then they left, and five minutes later the 'psychic' returned looking for her lost credit card or something. Priceless.

Just as the novelty of the eeepc was beginning to wear off, today I got a model 2 OQO in the mail. It's a pretty nifty little device. First impression on opening the box and pulling it out was that it was a little 'chunkier' than I was expecting. It's pretty heavy at 3lbs. A whole pound heavier than the Eee. Similar slide-out keyboard to the n810. Much bigger screen.

It comes with Vista pre-installed. I powered it up, just to make sure it's all working. This part took forever. It sat at a "please wait" screen for ages. After 15 minutes, and two reboots, I got to set up my user account. It then spent another five minutes "checking my computers performance" and god alone knows what else. During this time, the device got really hot, and the fans starting running full tilt. For considerable amounts of time whilst I was waiting for it to do something, I was staring at a black screen with a mouse pointer. I had no idea if it had crashed, or was actually doing something. This was my first vista 'experience', but before I'd even gotten to a desktop, I'd decided that modern Linux installations are leaps and bounds ahead in terms of user experience in this regard.

Finally, 25 minutes after I'd hit the on button, I got to a desktop. I moved the mouse pointer, and the screen changed to "shutting down". It rebooted. What was this, the 4th, or 5th time? I'd lost count. After another minute, it had booted up. I fiddled around a little, before quickly becoming bored with it. The fans ran almost constantly. Sitting at an idle desktop, vista pulled around 9 watts, with spikes every few seconds at 13W. Occasionally, it would go as high as 15W. Again, it was completely idle all this time.

After getting bored with trying to beat Vista into using my wireless, I rebooted, and found my way into the bios (Fn-Del). From there, a found numerous things to twiddle (like, enabling PXE as the first boot choice). Surprisingly, there was also a 'Enable ACPI CPU C4" option which was disabled by default. Enabling it didn't cause Vista to use any less power. I guess it's being woken up so frequently that it never gets into those lower states. Given Linux can and will exploit it however, I left it enabled.

Booted up a rawhide install over PXE. Idling, it bounces around 8.4 to 8.9 watts. This isn't an apples to apples comparison though. Sitting in Anaconda is a lot less intensive than an 'idle' desktop.

At this point, I hit my first problem. The ethernet (a Realtek RTL8139, which should be well understood) isn't noticing a link, and hence refuses to get a DHCP release. Some futzing around creating a debug initrd with a shell later, and I discovered that the chip gets discovered just fine. But with one caveat. It detects the MAC address as 00:00:00:00:00:00.

More poking later, but for now, I'm drawing a blank.

In comparison to last weeks excursion to the middle east, last nights gig was many kinds of awesome. Meat Beat Manifesto put on a real cool visual show. Total sensory overload. Of course, the music was also really good, with a mix of new stuff I hadn't heard before, along with a bunch of old favorites like Helter Skelter, Radio Babylon etc.

I managed to find a really good spot to take a ton of photos. Somehow I even managed to stay in a section that was later cordoned off without being evicted by the security guys like everyone else. Maybe they thought I was the band photographer or something. I wasn't complaining.

At the end of the night, I was somewhat relieved to not have a repeat of the craziness after last weeks show. Autechre had just walked off stage, and the security guys were marshaling us upstairs so they could close that part of the club. Ajax and I still had some beer left, so we took a seat, and finished. After which, we found out that we still had time for another, so the inevitable ensued. We were barely halfway through drinking when we were told we had to leave. Immediately. "Sure" we said, "just need to go the bathroom". I waited outside the bathroom whilst Ajax did his business. Shortly afterward, he reappears, and I enter. At this point, things go a bit weird. The lights go out. "Hey" I shout. The lights go back on. A few seconds later, they go off again. I holler again, but this time, no reactivation of the lights. Being a resourceful type, I happened to have a torch on my keyring. So I'm finishing up by torchlight, and finally emerge from the bathroom. Into complete darkness. All the lights in the place are out. Not a soul to be seen. "Strange" I think, and head to the door. Locked. Apparently from the outside. I wander around for a while shouting. No response. I wandered some more pushing doors to no avail, and then saw the fire exit. "This has to open" I thought, but then I hesitated. "What if an alarm goes off?". I pondered my quandary for a moment, before thinking to hell with it, and shoved the door open, and fled to the street, to bump into Ajax again who was wondering where the hell I had got to.

Crazy.

And then, we had pancakes. And all was right with the world again. There is no problem that ihop can't solve.

Post traveling epilogue.

• At some point in the evening I fell asleep with a laptop on top of me. Woke up at good knows what time, to turn off the tv & light, and returned to bed to sleep some more. Woke to find the DVR showing 8:00. Great, I'm back on EST. Sort of. Time passes. Look at DVR. 8:00. wtf? Press button on remote. 8:02. Wait, I've been awake for _hours_. Look at clock on laptop. 8:02. Look at clock in terminal. 8:22.
  At this point my brain stopped trying to work out what time it was, and I got breakfast.
  
• Breakfast.
  
  Pour eggs into container. Put eggs in microwave. Beep beep. Wait. Observe eggs cooking. Stir. Beep beep. Observe eggs expanding out of container. At this point someone sensible would have removed the eggs from the microwave. I am not a sensible person. The inquisitive side of me really needed to know "how big will they get if I keep microwaving them". beep beep. "Oh. _that_ big".
  I'm not good in mornings.
  
• Cleansing.
  
  There are two things that I really hate about air travel. One is that when I return, I itch. Seriously. To the point where I want to shave my face down to the bone. So I shaved. (But held back when I started seeing blood). The second thing, the dry recycled air for hours on end seems to trigger a nasal haemorrhage about 12 hours after I land.
  
• Unpacking
  
  I'm not sure why, but I hate unpacking almost as much as packing. With packing, I'm constantly doing that "what have I forgotten?" thing, taking everything back out to double check stuff etc. With unpacking, I'm just a lazy bastard. I've left suitcases of dirty laundry, cables, and random detritus sitting around for weeks before doing something about it. On this trip, I made a special effort. I unpacked, to find that my suitcase took a real beating. I noticed one of the wheels was breaking a bit in London, but it seems that one more trip through the system has finished it off. The frame inside is also mangled to hell, which caused a bunch of stuff I was transporting (like a Pot Noodle) to break. (the usual suspects will be happy to know the 'ass reaper' managed to stay intact).
  

Got back a few hours ago from my vacation in England for the last week. Got up this morning to face London in the pouring rain. By comparison, when I finally got back to Boston, I had to remove various articles of clothing to avoid passing out in the heat. A pleasant surprise to return to. It was great catching up with people in England, and not really doing much (isn't that the whole idea of vacations?), but the color of everything there was just slightly not good enough. The weather was pretty miserable the whole week, spare for an occasional gap in the clouds.

Tomorrow is definitely a "do nothing much except read email" day. There's just ridiculous amounts of it.
Also, due to ineptitude on my part, I just accidentally deleted a whole swathe of it unread. If you sent me something important, and I don't reply in a day or two, chances are it was in that batch, and you should resend.

Tonights gig wasn't all I was expecting it to be. Autechre's new album didn't wow me as such, but I still expected more from a live show than two dudes playing on their laptops in complete darkness. The support acts were the highlights of the night. Rob Hall held together a decent dj set between each band (probably the highlight of the whole 5 hours), and Massonix was at least interesting to watch, as Graham Massey struggled to keep beats in sync with his playing of various instruments. All I can say is that his style has changed somewhat since the days of 808 state. It was decent enough music, but I think he probably would have pulled it off better had he had a stage assistant for the triggering of loops etc.

Not a bad night out in all, but somewhat disappointing from the headliner. I didn't even feel compelled to buy a tour t-shirt. Also, you'd think most bands would have twigged by now that >1 shirt design = more sales. Offering the same shirt in three different colours doesn't really count.

Meh. Excessively bitter. 12 hours until vacation. Things can only get better.

Because all the cool kids seem to be doing it, I got me one of those twitter things.

Apr 13 05:06:53 pressure smartd[2553]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 253 to 252
Apr 13 05:06:53 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 176 to 104
Apr 13 06:06:53 pressure smartd[2553]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 252 to 253
Apr 13 06:06:53 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 104 to 64
Apr 13 12:06:53 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 64 to 170
Apr 13 12:36:53 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 170 to 197
Apr 13 13:06:52 pressure smartd[2553]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 253 to 252
Apr 13 13:06:52 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 197 to 162
Apr 13 13:36:52 pressure smartd[2553]: Device: /dev/sdb, SMART Usage Attribute: 199 UDMA_CRC_Error_Count changed from 162 to 84


What the hell? Aren't these numbers only ever supposed to move in one direction?

Sigh.

First the endless mails from people looking for the guy from the monkees, and now a new strain of this problem.
From todays mailbox..

Hi Dave
Just a quick word to say last nights performance was the best of the night.
Me and three friends saw you at the Johnny Vegas thing at St Helens theatre royal and we all thought you were funniest even if some of audience didn't know how to take your
humour you really tickled me and yes I've already started lookin for dvd's.
Ta very much
Pete.

I figure he meant this guy. I hope that dudes mailbox is full of people asking questions about kernel crashes.

Earlier this week, I noticed a posting from Andy Wingo about how he'd switched to Fedora from Ubuntu. Whilst I found his post interesting, I knew I'd find the comments even moreso. Certain things keep coming up over and over again, and I'd really like to know more.

• "Fedora is slower than ubuntu/debian/mepis/yourmom".
  
  Exactly 'what' is slower ? Every time this argument is trotted out, there's nothing quantifiable in there, which makes it a little difficult to investigate. We have all the same profiling tools as everyone else, so for someone experiencing this slowness, it shouldn't be too hard to identify at least the component that's causing this. (One thing that is well known -- we still really suck at boot up time. Working on it, honest).
  
• "Fedora has less packages than debian/ubuntu"
  
  No argument there. However, I'm curious exactly what packages people are missing that aren't in Fedora for this argument to hold any water. A few years ago, before we even had Fedora-extras, maybe this was a more valid argument. Today, in a post-core/extras-merge world, it's a rare case that I need something that isn't packaged. (And when it isn't getting it packaged up, reviewed and added to the repositories is usually fairly painless for a Fedora contributor). Looking at the package wishlist, there's a lot of fairly obscure stuff, but the list isn't exactly huge.
  What else do you miss from Fedora ?
  
• "I don't use Fedora because of rpm hell"
  
  It's a fair bet that anyone using this argument hasn't actually used Fedora in some time. Typically dependancy problems of this nature come from mixing repositories. Again, with the core/extras merge, there's even less reason for third party repositories to exist. One exception to this is the development repo, which sees transitional effects from time to time (sometimes on a daily basis) due to the amount of churn. That said, some of our dependancy chains really, really suck. The more egregious problems are usually bugs that need fixing on a per-package level, and not something inherently wrong with rpm.
  None of this problem is unique to rpm. I've seen apt/dpkg get into similar problems when mixing third party repositories.
  

The day kicked off with the power management mini-summit taking up the morning. Lots of discussion about things like Energy Star and EPA certifications and how they affect Linux. To the casual observer, this may seem deathly dull (and in honesty, that was my initial reaction), but there's a little more beneath the surface. Various US govt departments for example mandate EPA compliance for all new servers that will be bought after a certain date. How do you know if you meet compliance? You run a benchmark suite that is currently Windows only. Lots of discussion about how a Linux variant could be created, and what the actual certifications would mean to both vendors and upstream as newer versions of code gets released. Tricky problem.
The fact that this is currently windows only is hopefully a temporary problem, and there was some discussion as to how to engage the community, to see if someone would step up to help create an analog for Linux. Apparently BAPCO, the creators of the existing benchmark are prepared to do a Linux version, but at least the harness (which is actually the more boring part) wouldn't be opensource. I suspect if someone were sufficiently motivated, it would only be a matter of time before that part of the suite would be reimplemented. Further discussion ensued on whether this re-engineered version would be valid for certifications seemed to lean towards the positive.

Various other discussion surrounding the items that always seem to come up, wakeups, powertop etc.
The focus was mostly on runtime power management this time around, with little to nothing on suspend/hibernate.

The afternoon had some sessions, but I found myself wrapped up in various 'hallway' discussions with a bunch of folks.
Spent some time with Arjan talking about kerneloops.org, lots of interesting stuff there.

An evening of mexican food, Martguerita's & beer followed at the Iron Cactus. Good times were had by all. (Though no barmen performing pyrotechnics this time).

Heading back to Boston tomorrow. I've got a bunch of stuff to chase up when I get back, on top of the obvious backlog from being away for the week. Busy weekend ahead I guess.

I bailed on the collaboration summit today. In part because there was a bunch of stuff on the agenda that didn't really shake my tree, and in larger part, because Matthew Garrett and myself got invited on a tour of Centaur Technology's offices here in Austin.

I'm really excited about their next gen CPU after what I saw today. I've always had a soft-spot for Centaurs CPUs. In part because the IDT winchip was responsible for my first 'real' set of changes that I got into the Linux kernel nearly 10 years ago. They've always been an extremely linux-friendly company, so I was prepared to be buried in patches to make their new design work with Linux, but it turns out that won't be the case. From what we've seen so far, Isaiah requires no changes at all to boot/be functional. We need a few tweaks to make us take advantage of certain features, but this sort of window dressing is something to be expected.
When this CPU is launched in a few months, Fedora (and probably just about any other Linux) should 'just work' on it (I already saw F8 running on it today), so I'm whilst I'm looking forward to not having to spend weeks patching the kernel and pushing updates to make it work, I'm also really looking forward to seeing what else we can do to push this CPU even harder. Also, as this is a completely new from the ground up design for those guys, they've fixed a lot of long-standing problems with the earlier designs, including the number one gripe from most people I've spoken with who've run C3's.. the performance. The new gen looks like it may actually be a really competitive part. Just how competitive it will be by the time it gets to market, compared to the Intel chip du jour remains to be seen, but the gap I'm sure will be a lot less than it was in previous generations, whilst still remaining really low power parts. Really interesting stuff.

I saw a whole bunch of processes that I'm in no way qualified to describe but were impressive to watch, and saw some really interesting work being done to analyse performance and power usage. With such a small team, I'm truly amazed they accomplish so much. I'm pretty sure this is entirely down to way the place is entirely run by its engineers. From Centaurs website: "There are no managers at Centaur. Instead, employees report to Centaur founder and President, Glenn Henry, an engineer who was a fellow at IBM for 21 years and a senior vice president at Dell.". When the president of the company is also the guy that ends up writing the microcode for your products, I guess you're going to achieve things a little faster than you would in a company with multiple layers of management, endless meetings and red tape. After recently reading The pentium chronicles, it was a real eye opener today to see just how much can be achieved by motivated people passionate about what they do. In many ways I found a lot of parallels between Centaurs engineers and those at Red Hat or many other Linux companies. Little wonder we work well together I guess.

I'm in Austin, Texas for the week for the Linux Foundation collaboration summit. Yesterday I took part in a panel along with a half dozen other kernel developers, which was fairly uneventful. No really difficult questions. Perhaps (like me), lots of the audience weren't morning people, as the afternoon panels were a lot more lively.
Had a number of interesting discussions with people about all sorts of things kernel and/or Fedora related throughout the day.
I had expected some of the talks during the first day to bore me out of my mind, but I was actually pleasantly surprised at how interesting some of them were. There was a talk from someone at IDC whose name I'm blanking on who rattled off dozens of interesting statistics about Linux adoption over the last 10 years, and possible projections into the future. Perhaps a little hand-wavy, but it brought out the statistics geek in me for an hour at least.

Something else I found of interest was the increased number of companies who have formed some form of 'mobile initiative' and are 'forming a community' around their cellphone/tablet/pda/whatever device. Something that irks me is the notion of taking code from an existing community, and adding customisations to that code without involving any of the stakeholders of the original community, with a view that "people can join our community if they want to get involved" and "when we're ready, we'll push this work back upstream". This bothers me for a number of reasons.

1. The obvious.. "what if the upstream project doesn't like your changes?". You just wasted 6 months and have to either go back to the drawing board, or ignore the upstream project, and continue maintaining your fork^Wcommunity.
   
2. The notion that "anyone can join our community" is a nice gesture and all, but we have a functional community already. The one from which your changes are being based. The idea that an upstream maintainer has to join another 'community' for each vendor that decides to do this model is a ridiculous expectation.

For a long time, kernel developers have been complaining about how so many 'embedded' companies have parasitic behaviour, taking and never giving anything back. This current trend seems to be the next evolution: parasitic communities. (Or what we used to call: a fork). I hope I'm being overly negative, and the future won't be the dystopia that this trend seems to be heading towards.

The evening saw some venturing out to Downtown Austin for lots more discussion & mingling at a bar with a shark pool in the floor. Novel I guess. Afterwards a bunch of us headed to 6th street in search of further entertainment. Much fun was had involving 151% proof rum, amaretto, beer and fire. Somehow we all left with our eyebrows intact. The evening ended with a renewed hatred for karaoke, and getting back to the hotel at not too obscene an hour.

I found these numbers interesting.
(I only focus here on packages that had >100 bugs filed against them. Bugs are counted regardless of their state [open/closed/whatever])

FC1
Total number of bugs filed across all packages: 3109
Out of those, kernel made up 442, followed by anaconda at 192 and XFree86 at 111. Everything else was < 100

FC2
Total number of bugs filed across all packages: 4043
kernel takes the lead again, at 1053 bugs. Ouch 1 in every 4 bugs. This was the first release we switched to the (then new) 2.6 kernel. Anaconda took second place again at 237 bugs.

FC3
Total number of bugs filed across all packages: 7367
Did we get a lot buggier? Or was this the increased testing that happened, due to this release coinciding with RHEL4. I'd like to believe the latter. With an increase in bugs, the number of packages scoring > 100 bugs filed also increased.
Anaconda at 452
Xorg at 270. I guess as XFree86 stagnated, the bug count previously stayed low.
Evolution at 149
Yum makes its debut with 133 bugs
SELinux-policy-targeted at 142 (I think this was the first release we introduced targeted policy)
Firefox at 118
Openoffice at 111
None of them come close to the kernel, which amassed a staggering 1190 bugs. (I'm not sure how I didn't have a meltdown at the time, when I was also juggling RHEL4 kernel bugs).

FC4
Total number of bugs filed across all packages: 7602
Interesting. No post-RHEL4 drop-off.
Kernel breaks its personal best with 1213 bugs. I think the 'one person managing multiple releases' cracks were beginning to show.
Anaconda: 583
Openoffice: 222
Xorg: 218
SELinux-policy-targetted continues to rake in the bugs: 171
Yum still 'not quite there' at 169 bugs.

FC5
Total number of bugs filed across all packages: 8487
Kernel in the top spot yet again, at 1381 bugs. (The highest of any release so far)
Anaconda: 617
Gnome-themes: 222 (This statistical anomoly seems to have been caused by an enthusiastic bug filer clicking submit several hundred times)
Pirut: 139 (It seems there's always a spike whenever we introduce a new tool, especially if its something fundamental like a packaging tool)
SELinux-policy-targeted: 124
Openoffice: 120
Firefox: 109
Xen: 105 (Another high-scoring debut)
Worthy of an honorable mention: This release marked the introduction of modular Xorg. Because of this, all its bugs got scattered across multiple packages. Added together: 263 bugs.

FC6
Total number of bugs filed across all packages: 7792. The first release where we actually saw the overall bug count go down.
Kernel: 981 (This also spawned kernel-xen, which amassed 98 bugs)
Anaconda: 474
Xorg (cumulative across all packages again): 297
Yum: 221
Pirut: 177
SELinux-policy-targeted: 114
Firefox: 106
Xen: 105
Compiz: 100 (Another introductory high-score)

F7
Total number of bugs filed across all packages: 5672. Quite a huge drop in overall bug count. (Note F7 is still open for a little longer for new bugs, but this drop does still seem dramatic)
Kernel: 744
Anaconda: 238
Xorg (cumulative): 173
Yum: 202
SELinux-policy: 155
SELinux-policy-targeted: 119
Pirut: 153

F8
Total number of bugs filed across all packages: 6818 (F8 is also open for new bugs for quite a while, so this is impressively high)
Kernel: 788
Anaconda: 287
Xorg (cumulative): 259
Pirut: 207
NetworkManager: 153
SELinux-Policy: 146
SELinux-Policy-targeted: 128
Firefox: 100

There are some pretty atrocious bugs in the PXE ROM on the eee pc. Little wonder it's disabled by default. I noticed that it would typically allow me to do an install, and then on reboot, it would tell me to check that the cable was plugged in. Looking at my network switch confirmed, there was no link. I puzzled over this for some time, doing the obvious things like assuming flaky cables, trying different switch ports, all to no avail.

Making this even more frustrating, powering off and back on doesn't cause it to go back into a normal state.
The magic to make things work again seems to be powering off, removing the power cord, powering on on battery, and then plugging the cord back in. For some reason, whilst on battery, the PXE ROM does a 'wake up the link detection magic', which it doesn't do when on AC.

Ebay drives me nuts. I created an account when I lived in England, and used ebay.co.uk periodically to score various computer arcana that in hindsight belonged more at the dump than it did in my front room. When I moved to the US, I found ebay helpfully let me use ebay.com with the same account, and imported all the relevant data from the .uk site. A nice feature, as it meant I kept my feedback 'score' and history. There are a number of quirks however that drive me absolutely nuts.

When ebay sends me email (like if my preset searches triggers when someone lists a new item), it includes a bunch of helpful URLs in the email to go directly to the item. Except it always starts the url with the .co.uk site. This may not seem like it's immediately a problem, except that this affects a ton of things like the price of the item gets listed in ukp. Various other parts of the site really don't mesh together well when you mix countries, and worst still, there seems to be no way to really 'emigrate' your online persona to 'always use the .com version of the site'. [and yes, the preset searches are set on the .com site, not the .co.uk site]

This has been driving me nuts for years now, and I guess it's enough of an edge case that no-one at ebay is aware it could even be a problem. The only way to solve it unfortunatly seems to be 'close all accounts and open a new one' foregoing all the aforementioned feedback history.