FUDCon hotel registration.

To remind everyone about FUDCon hotel registration — please visit the following link for hotel reservations:

FUDCon F10 Hotels

The link at that page will guarantee you the lowest rate at the hotel. If you make reservations at the Summit hotels outside this link, that will probably not happen. (These hotels are usually about twice as much as the rate for which we’re getting them.) Red Hat also gets credit for that room on its tally, which helps the event staff.

For those people looking to share a room (or any crash space), here’s what I suggest:

1. Mark the wiki page’s attendee list, under “Comments,” saying you either “will share,” or “need to share.”
2. Look on the list and see if you can find someone who has marked the opposite comment.
3. Offer to share, or ask if you can share, a room or other space.
4. Once you have an agreement, mark the “Comments” again to say you’re “sharing with [person's name]“.

Think of this as the BarCamp methodology applied to lodging.

_{UPDATE: Note to self — talking about links not as good as providing them.}

New addition.

I was very pleased to make this announcement on Tuesday night: Harald Hoyer has been selected by Red Hat to fill one of the appointed seats opening on the Fedora Board.

The Board and I are very excited to have someone from Red Hat’s Stuttgart office representing the European Red Hat and Fedora community. Harald’s pages talk more about his very extensive technical background, but I’m sure you’ll be hearing more from him shortly about his outlook for the next twelve months as a Board member.

I’ve since found out that Harald is going to be at LinuxTag next week, so I’m looking forward to meeting him in person then. Welcome to the Board, Harald!

As the message also states, Karsten Wade is staying on for another release to even out the elections. Red Hat will announce its final appointment after the elections end, so we can balance the skills and backgrounds on the Board properly. In the long run that means decisions are made after consideration from many points of view across the entire Fedora community, and better representation for all the constituents.

Nominations continue until as late as the 12th of June — if you’re interested in running for a Board seat, please fill out the Nominations page, and hit the campaign trail! (It is the season, after all.)

Won’t you [buy my] home, Bill Bailey?

Seriously, my wife is really tired of keeping this place spotless.

import realestate

myHouse = realestate.House(mlsNumber)
myHouse.sell()

Hey, it worked in xkcd.

And helping the elderly across the street is good, too.

Spot on, Greg. We want all package maintainers to relate with the upstream providers, because that extends the work we do in Fedora to all Linux providers and consumers equally. Besides the fact that this is just good FOSS citizenship, it also contributes to fixing a huge meta-problem across the Linux landscape — that users can have vastly different experiences using different Linux distributions, beyond the paint jobs. When code works in one place and doesn’t in another, it’s too often due to maintainers either (a) not sharing fixes back with the FOSS ecosystem, or (b) carrying patches that upstream won’t take because they are deficient. Either case is ultimately a lose for both users and developers.

That having been said, the difference in the ramifications of a bad patch to something like a desktop applet that shows you a happy face, and something like glibc or the OpenSSL libraries, is a pretty fair gap. We should protect one — or at least be concerned about one — more than the other. I’m not sure it’s as simple as applying a formula, but it could be that there’s a core of system libraries in which any non-upstreamed patches are going to be subjected to much more rigorous review before they’re used.

And in all cases, we should prefer, by a wide margin, getting those patches upstreamed. Our experience in Fedora over the years shows that carrying these patches only as temporary backports works well, not just in maintaining a strong relationship with upstream providers, but also in gauging the health of the upstream community.

Thank you sir, may I have another?

Francesco graciously points out some glaring omissions from my list of Italian Fedora Ambassadors, including Samuele Storari and Matteo Castellini. I’m overjoyed to hear this team is even bigger than I thought!

I got the full names of everyone on the team from our list on the wiki, since I knew I wouldn’t get names spelled correctly otherwise. I’ve added Samuele and Matteo there, as well as some anchors to make it easier to link to your region.

Are you a Fedora Ambassador? Is your name on the list? If not, add yourself today!

On the brink.

I sent some thoughts to fedora-announce-list tonight about the upcoming Fedora 9 release. An enormous and sincere thank you to all our contributors for making this such a great release. Just a little over eleven hours away…

Lesser known contributors, Vol. 9 Issue 2.

It’s time for another post where I introduce you, Constant Reader, to another Fedora contributor you may not know personally, but who deserves some recognition. With this post, though, I’m actually naming a whole crew instead of just a single individual: the Fedora Ambassadors of Italy!

I haven’t had the chance to meet these folks personally yet, but the amazing crew of Andrea Gnerre, Andrea Rossi, Sean Carlos, Francesco Ugolini, Giuseppe Pignataro, Marco Palazzotti, Mario Torre, Francesco Crippa, Elio Tondo, Gianluca Varisco, Luca Foppiano, and Lorenzo Villani have done inspiring work to make Fedora so popular in Italy. Their contributions really span the whole gamut from governance to daily hammer-and-nails work on the distribution.

Francesco Ugolini, for example, serves as the Chair for the Fedora Ambassadors Steering Committee (FAMSCo), which guides and empowers the worldwide community of volunteers who bring Fedora to the masses. Many of you may have seen the recent reports by Francesco Crippa debuting the new LiveUSB station they created and used at the liberaMENTE conference. One day, Max was tossing around the idea of how cool it would be to be able to burn Live images to people’s USB keys at a show booth, and practically the next, the Italian team had coordinated the creation of a big posterboard with beautiful art and a USB slot to make your own Fedora while you wait. It’s amazing to see random thoughts (”Wouldn’t it be cool if…”) turn into action through the ambition and dedication of some excited volunteers. And moreover, they plan for the future too — there’s a Fedora 9 version of their booth display on the way!

While I’m name-dropping his countrymen, I’d also like to give a much deserved shout of recognition to the incomparably efficient Francesco Tombolini (or “Tombo” as we affectionately know him). Tombo’s team is pretty much the fastest I’ve ever seen — I have NO idea how they get things done so fast. I’m sure he will credit many others, and they all have our gratitude, but thanks for rounding up such a great team, Tombo!

And thanks to all the Italian Fedora contributors, wherever you are — bravo!

And now, I return you to your regularly scheduled Time of Waiting for the big release of Sulphur tomorrow!

Slipping behind.

The only problem with putting your head down and your back against the stone is that sometimes you almost miss out on the scenery.

Dear Trent, I’m guessing you made out pretty well on that whole Ghosts I-IV thing. Thanks for putting the bastards in their place with another CC-licensed release. And by the way, you’re welcome.

Flushing the pipes.

It’s true, we had some problems with permission bits and rsync last night with the release candidate, which has resulted in some incomplete leaky mirrors. Users who try these mirrors may find that they don’t get what they’re bargaining for, because of missing bits. (Not to mention which, everything’s still subject to change until the 13th in case of fire or flood.) We’re really happy everyone is so excited about Fedora 9, but please don’t encourage silly fanboy behavior that might result in someone having a bad experience with Fedora. We want to make sure people thoroughly enjoy installing and using the distribution we all know and love so much!

(Thanks to the folks who alerted us to the problem.)

UPDATE: Our trusty release engineers tell me the leaked bits were not the final bits. If you hold on to any bits until May 13th, you can probably use jigdo to update them to the true final release bits.

A disk, by any other name.

Karsten, I don’t think we should be using, or telling others to use, the /dev/sd* device names at all anymore, when there’s a far better alternative — /dev/disk/*.

The /dev/disk/* namespace has several ways for identifying your disks beyond a shadow of a doubt. For instance, /dev/disk/by-label/* files show your non-LVM mounted disks by their filesystem label. Generic USB keys with no volume label would show up as disk. So a random generic USB key on my desk shows up as /dev/disk/by-label/Frields4G.

The only drawback to by-label is that if you use more than one unlabeled device, the labels disk, disk1, and so forth are less than helpful. So that’s why I tend to use /dev/disk/by-id/* files instead. These are long and messy, but that’s what your Tab key is for. They positively identify disks by bus, model, and serial number, along with partition numbers. For instance, that same random generic USB key of mine is listed as usb-_USB_FLASH_DRIVE_1954132606FA-0:0, with or without a -part1 at the end for the first primary partition.

I always used /dev/disk/by-id/* in my previous life where I’d have multiple hotplug disks, some of which were irreplaceable, attached to my system at once using USB and/or IEEE-1394 carriers. Now, it *is* possible for a lot of generic USB keys to look alike, but certainly between by-label, by-id, and being able to easily unmount and unplug a USB key quickly — to see which key matches in a touchy situation — users should be OK.

I’d encourage everyone to use /dev/disk in any user documentation or tips for modern Linux systems like Fedora, since it avoids precisely the problem Karsten is talking about. Of course, in the future, I’d hope we’d see a PyGTK version of livecd-iso-to-disk that makes this easier, only showing hotplug disks by default in the interface. It’s probably not far off!