Archive for July, 2008

Beantown ho.

It’s not an epithet, it’s a slogan. I’ll be up in Boston (Westford, actually) for the week of July 28. During that time there are a few things I’d like to accomplish, like:

  • getting together with some of the Red Hat managers who don’t see me often (you know, out of sight, out of mind)
  • Figuring out some preliminaries on how we’ll handle FUDCon F11, financially and logistically
  • Kicking Casey Dahlin out of my cube, just ’cause I can (just kidding, Casey)
  • making a video with someone on the Desktop team (or any team, for that matter) who wants to show off a cool feature
  • Rooting out and educating folks who want to participate in the Fedora 10 and Fedora 11 feature processes but aren’t sure how
  • Enduring jibes from picking the worst time ever to sell a house in the last two decades

This time around, no one has to put me up in their pads. In the past I’ve crashed with folks on these trips, because I care about saving the company money wherever possible. But what I realized was that the $100 a night I was saving the company in hotel was not a savings at all. Without a hotel on a trip, I lose about a third (or more) of my normal work hours. Which comes to hundreds of dollars a day in lost productivity.

So this time I’ll be staying at a nearby hotel so I can get into the office earlier, work after hours, and have a place to wear my wooby shorts. I’ll still be able to make time to go to lunch with folks, maybe hang out after work one night, and so on — because I have that extra time banked in which I know I can keep all my tasks properly juggled.

Beat writers needed.

As we approach the Fedora 10 Alpha release, the Docs team finds our list of beat writers for the Release Notes is sadly outdated. We need to get it updated with people who are willing to write information on Fedora 10 changes.

A “beat” is like a policeman’s or a journalist’s beat — a small, easy-to-maintain page that is targeted at a specific part of the Fedora distribution. Writing a beat is easy, and gets you dialed in to the developer community (if you’re not one). You simply make sure that you’re capturing important changes that will impact users, developers, and administrators who try and use Fedora 10.

All your work can be done on the wiki, which means that anyone in the Fedora community who’s completed the CLA can do this job. You don’t even need to be a great writer — Docs team editors will clean up the wording if needed and make sure it’s digestible for the readers. You just provide a bit of elbow grease for the raw content, they can do the rest.

If you want to find out how to help, come by IRC Freenode #fedora-docs, and/or sign up for the fairly lightweight mailing list. It’s a great way to get involved as a contributor.

Heads up.

The privacy policy we’ve used in Fedora for years has been causing us some conflicts recently. The only big surprise is that it’s lasted for this long! That’s because it’s Red Hat’s privacy policy — and it’s designed for a commercial entity that deals with customers, not an open and transparent project to which people publicly contribute materials.

Here’s an example: Recently, we found that the policy was going to make it impossible for us to develop useful geographic data on contributions. We can use data like that to develop the infamous “heat maps” to show where lots of Fedora work is happening. Those maps have been absolutely instrumental in our community architecture plans, and how we devote resources to Fedora worldwide.

Even though we’re always very careful about aggregating this data so it’s not tied to individuals, the old privacy policy still prevents this and many other, similar reasonable uses. We can develop metrics that are useful not just to the Board, or FESCo, but also Ambassadors, Marketing, and other groups. These are all our fellow contributors whom we already trust, and with whom we share our account system.

Moreover, some of this data is intended to be public already — data like your Fedora Account System (FAS) account name and email; or the fact that you used it to commit a specfile patch; or the fact that you uploaded that patch from a certain IP address. So the privacy policy we’ve been using is completely out of whack with the reality of a truly open project like Fedora.

Thankfully, we have a proposal from Tom ‘spot’ Callaway that will fix some of these gaps, and improve the transparency of our project. The new policy, and FAS, will continue to keep absolutely private your vital personal information, like address and phone number. And the FAS will provide “opt-out” capabilities for any project member who does not want to share their other data.

The fedora-advisory-board mailing list has a thread to discuss the policy. After a discussion period over the next several days, the intention is to submit it to the Board for a vote.

If and when any such privacy policy change happens, we’ll notify all account holders. As always, we want to make sure our contributors’ private data is completely secure, while still bieng able to promote the openness and transparency of the Fedora Project overall.

Go go AllemaniACs!

You might remember the AllemaniACs Robocup@Home team from this Red Hat News article. They use Fedora for all their programming and onboard their robot soccer team, and they’re in Suzhou, China this week for the RoboCup@Home world finals, after winning the German Open in Hannover earlier this spring.

Earlier today, we saw that at the end of the first day of the competition, the AllemaniACs are in first place. Congratulations to Tim Niemueller and the rest of the AllemaniACs team!

Find out what it means to me.

One of the last things I want to worry about as the Fedora Project Leader is the appearance of our community. We have so many bright, energetic, talented, and wonderful people helping build the future of free and open source software, that I sometimes take it for granted. The work that we’re doing, I think, is making a better world not just for us but for our fellow human beings too. And we’re open and transparent about everything we do, so everyone hopefully can see that same vitality when they look at Fedora.

But doing this work is more than just moving bits and bytes around. It’s remembering why we do it. If our work is accompanied by disrespect for our fellow human beings, what good does all the free software in the world do? “What doth it profit a man…?” It boggles my mind that people must be reminded their behavior reflects on them and on the groups with which they’re affiliated. Nevertheless, that’s exactly the sort of reminder this is. Read on if you care.

Read the rest of this entry »

Pending relocation.

A quick note on my geography, for those who care.

When I was hired by Red Hat, it was by the Engineering department. Previously, my position, as held by the illustrious Max Spevack, was located in the Corporate Marketing deparment of Red Hat. My intention was (and remains) to relocate to New England somewhere around the Westford, Massachusetts office.

My wife and I went so far as to go on a preliminary house hunting trip, during which we quickly decided we really liked New Hampshire. Westford is only a few miles over the state border from Nashua, NH. (Whether this was advisable before we had an offer on our house is moot, given our unfamiliarity with that area.)

Our house has been on the market since late February but the extremely poor USA housing market has stifled our attempts to sell it. We will likely be dropping the price again, but one of the problems we are facing is the discrepancy between the plunge in our local market — roughly 30%+ in the Washington, DC area — and the less precipitous drops in New England. Meaning, if we drop our house price so low that it stands a good chance of moving quickly, we also put ourselves in the situation of not being able to afford housing at our destination.

I’ve been developing somewhat of an ulcer over this issue, but fortunately the folks at Red Hat have been very understanding. We’ll be leaving the house on the market and doing what we can within reason over the next few months, but if we haven’t sold the house by the middle of autumn, chances are we will stay put in Virginia until next spring.

Fortunately, since we no longer have a big hole in our kitchen ceiling, the house is back to its very attractive former condition. We still have repair pending on our master bathroom shower to replace some drywall and tile. The experience of the unfortunate leak and the attendant repairs hasn’t done much to increase my estimation of the general contractor industry, but at least the end of this particular engagement is in sight.

Insert sounds of engines revving.

A couple of days ago, the big heads-up about new RPM hit the lists. Today the other shoe has dropped. Thanks to the RPM hackers working on this codebase — many distributions are going to benefit directly from this work, including but not limited to Fedora.

Careful with that axe, Eugene.

I think everyone can agree that when one gives Fedora help to someone, one should give the right answer. There’s been a little confusion over in #fedora about making bootable Live USB keys.

In the old days, you used to be able to use a command like this to make a minimal, bootable USB:

dd if=bootdisk.img of=/dev/sdX

But the bootdisk.img file was a bitstream image of a bootable disk (in the hard disk/floppy diskette sense), not a CD. An ISO file, which is a bitstream image of a CD/DVD, has a very different structure from a disk image — whether the ISO is bootable or not. So the following command won’t work for making a bootable USB key from an ISO:

dd if=image.iso of=/dev/sdX

There are several requirements for booting from a USB key. One is that your system’s BIOS has to support USB booting. Another is that the USB key hardware has to be responsive to that feature — not a foregone conclusion, unfortunately. Certain system BIOS implementations don’t seem to respect some USB storage devices.

It’s a hardware problem that we can’t solve with the operating system, and it’s unfortunate. But at least you can test this sort of behavior before you buy a unit, hopefully. And if you like the computer system enough, you can always switch USB keys, since they’re a lot cheaper if you buy several different models! ;-)

On x86 and x86_64 platforms (I don’t know much about ppc), the BIOS reads the first sector, or 512 bytes, on the boot device, and executes some code there. In some cases, like hard disks, that means reading a partition table and possibly moving to a different location to continue booting; in others, it means executing boot code found there. (This is where the first bit of the GRUB boot loader is found, for example.)

ISO images, however, don’t have any of this information in their first 512 bytes. So if you simply write out the ISO image onto a disk device, it won’t boot. Your BIOS might throw you an error, or you may simply not be allowed to boot from that device at all.

Which brings me to the two ways that do work for making a bootable USB from our Live images: the livecd-iso-to-disk program (part of the livecd-tools package in Fedora) and the Windows program LiveUSB Creator. These programs set up your USB key with a real boot sector that allows your BIOS to find the next bit of code it needs to continue booting.

One problem I see is there’s some ground not covered in those two solutions alone. How does a user of another Linux distribution, who doesn’t either dual boot Windows, or have a CD/DVD drive available, make a Live USB key? Granted, this will be a fairly restricted subset. I know there are other distributions that carry the livecd-tools package. Our documentation should reflect how to use it on those distributions. If you run one of them, and can write a quick series of steps, the Docs team can beat it into stylistic shape!

Sometimes there’s a man.

Another thought about the feature process: I suppose you could look at quality as a concept driving the feature process, and quality is what dictates having an acceptance bar. Because if you’re not going to make any judgment on quality, then really, anything goes.

This might, to some, beg the question of putting the cart before the horse, but I’d say it’s more of a chicken and egg problem. A call for better quality goes out, a system emerges to fill that need. Simply having that system, any system, leads to more energy, whether through friction or impulse. (That’s a lot of metaphors for one paragraph.)

The feature process itself has fortunately had people willing to work on it, take input, improve it, and get traction. If some argue that the process has its flaws, I’ll certainly agree (as would everyone who works on it, I imagine). But better to have lopsided growth than stagnation. Concrete suggestions for correcting said growth patterns is cheerfully accepted, as John Poelstra pointed out earlier.

Ch-ch-ch-ch-ch-changes, no. 38.

True to form, Fedora marches on! As I look at the proposed Fedora 10 features this morning, I see a lot of changes since yesterday. The number of feature proposals has dropped significantly, meaning these features have been simply moved to a more general pool while their owners update them with a bit more data. That extra data allows for better discussion of the feature and how to measure its progress or completion. I would expect that many or all of these features, and hopefully more, will find their way back to the proposed list very shortly.

There is still plenty of time to propose features for Fedora 10 — and whether you are proposing one as a developer or as a wish, the feature process can accommodate you.

Update: stupid process grokkage mistake, duly fixed.

© 2002-2012 Paul W. Frields License: CC BY-SA 3.0. Some rights reserved.

Switch to our mobile site