Jeremy’s Thoughts

This week (and last) saw me spending a bit more time on “Fedora-y” things than I have been over the past while in an effort to try to help shore various pieces up in preparation for the Fedora 11 beta. Although the beta is actually going to go out a little later than the initial plan, it’s been a good run and there have been some good things accomplished.

First on the list was testing out the livecd. As is often the case, there were a variety of things which had either entirely or partially broken. Also, there was a (good) suggestion to go ahead and install xguest with the live image so that people can take advantage of the good work that Dan has done there. Luckily, this was all pretty straight-forward things and involved a few fixes here and there.

They did, though, highlight the fact that we lose out on some pretty valuable testing by not making live images available more regularly. The problems always come down, though, to how would we distribute such images — the mirrors probably wouldn’t like 700 megs x 2 arches x n spins (at least desktop + KDE would make sense) churning on a daily basis I don’t think. Especially since live images aren’t rsync-able. Would people be okay with torrent only distribution of more frequent snapshots? And be okay with live snapshots that were just produced in an automated fashion without any testing at all before they go out? Comments appreciated

The bigger thing that took some time was helping to get the new anaconda storage code working with the live install. This is something which isn’t big and glitzy because right now, it’s all unglamarous backend code. But Dave Lehman hammered out a nice start to overhaul the storage code in anaconda to take into account more of the things which are “modern” storage/partitioning needs. This has then been supplemented by an avalanche of patches from the rest of the anaconda team to get things into shape. My patches were some small ones to deal with some of the more interesting quirks with how we do an install from the livecd. Luckily, as of this afternoon, it looks like we have something there that will work pretty nicely. A shout out to the anaconda dudes for the hard work they’ve been putting into getting it into shape and pulling out what was one of the last pieces of anaconda that’s more than five years old. In Fedora 12, hopefully we can move on to the next step which is overhauling the user experience for partitioning in a major way.

Fedora anaconda, livecd

Scott@Ubuntu has posted a few times over the past week or so about some of the problems he’s hit while using git and the more I think about them and read them, I think that a lot of it comes down to expectations of a very different mode of working than the git developers "push".

The git way seems to largely be that the most common way for someone new to contribute code is that they write a patch (or series of patches), commit them locally, and then send them via email for review and eventual merging. These are made easier through the existence of commands like git format-patch, git send-email and git am (apply-mailbox). These really are wonderful tools if your workflow is around using email for patch review and merging as is done in the kernel and many other places. There’s certainly an argument to be made that this sort of mailing list review ends up improving code quality. But it’s not the only way. And since git is about there being multiple ways to do things, maybe some of the other ways need to be made easier too…

One of the ones that seems to pop up commonly is that people want to have their trees available for others to pull from/merge in. This is doable today, but as Scott notes, it’s not entirely straight-forward and requires some knowledge of how to set things up. What if, instead, there was a git publish command that was able to essentially push your working branch to a remote location (via ssh/scp) and do the things necessary so that it’s clonable via http out of the box and not require any initial login and creating a repo, etc. The question that comes to mind is “if I run git publish again, how does it differ from a git push” and the answer is probably not much, but I’m open to other opinions

The obvious second step after that would be to add easy-to-use support for publishing to somewhere like gitorious. That would help for people who don’t have web hosting or a number of other things. And that is a gap that bzr ends up filling by allowing people to use launchpad for arbitrary bzr hosting.

The other workflow that might be interesting to better support would be something like Review Board. I keep wanting to set up an instance to play with and possibly even have people use for things like livecd-tools or anaconda patches. It seems to combine some of the upsides of mailing list review (easy for all to see, easy to annotate changes, …) without some of the downsides (mailing lists suck, a topic for another day) There’s some movement underway to try to get an install going for Fedora Infrastructure, so if you’re interested, help is wanted!.

What do people think? Would a git publish command as described above (minus the aside of the Review Board stuff) be useful/interesting?

Fedora git

A few weeks ago, Yoav recommended Steve Krug’s Don’t Make Me Think as a good book on web usability. I added it to my never-ending list of things to read, but since I’ve been poking around in some things which are a bit more web-y in addition to some of the MyFedora stuff going on (not that I’ve been paying as much attention to the latter as perhaps I should), I decided to bump it up in the queue rather than having it languish on the list forever. Luckily, the local library had a copy which I requested, picked up and finally had a chance to sit down and read it.

The book was a quick and easy read. There’s really not anything ground-breaking or revolutionary present, instead, it’s a good overview of lots of common sense things. And even though it’s a few years old for the most recent edition, it tends to still apply today. It would be nice to see an update taking into account some of the impact that AJAX has had on web design, but I’m not certain that the impact is really that large for what he’s really focused on.

The most basic point really is to make things obvious. Don’t think that you’re a whizz-bang designer and can make something incredibly new in terms of interfaces for the web unless you’ve really really spent a lot of time testing it out. Because even though the obvious is boring, the very fact that it’s boring makes people comfortable.

The other key point that he stressed that should be obvious to people developing software is to test early and test often and then iterate. It’s better to test the same web site twice with 3 people each time than to test once with 8 people. Again, kind of obvious, but too often passed up on in the effort to build something “beautiful” the first time.

If it were an incredibly long book I would have gotten annoyed by some of the simplicity of it all but at about 200 pages it was perfectly effective. So if you’re working on websites, I’d recommend reading it either by buying a copy or by visiting your local library.

And as a side note, your local library is a wonderful resource that too many people neglect. I’ve been making it a point to check more books out from the library over the past few months as opposed to purchasing them. I figure I’ll turn around some of the money I previously spent buying books to support the library and have the benefit of more to read and less clutter in my house. But the ability to go to their website, request books, and then just drop in and pick them up, read them, and return them is great.

Fedora book review, usability

As some may have noticed, I’ve been a little bit less active on the Fedora front of late due to looking into some new areas (more to come about that later probably). To try to keep my fingers in a little bit, consider this a standing offer from me to try to do some more package reviews. If you have a package that you feel strongly about getting into Fedora either to support a feature you’re working on or to start some interest in new areas or even just to take care of a long-nascent merge review, let me know in one of the usual ways (email, irc, etc) and I’ll try to get to it. My goal is a very modest one a week, but hopefully it can help some with the review pressure. And if all of the Fedora contributors who had been around for a while would make the same sort of offer, then we could make even more progress.

Thanks to bpepple for unintentionally encouraging me to do this (I’ve been thinking about it for a while, but never get around to it) by asking for a review on fedora-devel-list last night!

Fedora package review

As people may have noticed, I’ve mostly passed the dracut torch on to davej and he’s done a more current status report which has been picked up by lwn for this week’s kernel section.

Now, if we could get to people actually commenting on the core ideas of being entirely event driven and helping to fix various poor kernel/userspace interactions there (device-mapper’s integration with udev is poor and mdadm’s incremental mode didn’t work for me when I tried poking at it last) maybe there’d be some progress. Unfortunately, klibc and busybox and $existing_tools end up being the core of any discussion anywhere.

And it’s that propensity which sometimes make me unclear on the future of Linux. :-/

Fedora dracut

It keeps coming up that people would like to support multiple live images running off the same USB stick/hard drive/$arbitrary medium and so it’s probably worth considering some of the ways that it could possibly be supported.  Also, for the personal reason, it would make it easier for me to effectively use my netbook with the super-slow SSD if I just put a new rawhide live image on it regularly and keep my homedir on the (faster) SD card

Breaking it down into components, I think there are a few things which we have to worry about

1. Where to put things on the disk. 

   The more I think about it, the more I think that having “everything” for one image (including the bootloader bits) will be easiest.  The suggestion of using the iso label for namespacing seems to make reasonable sense.

2. Boot loader config

   There are a couple of possibilities here… the simplest would just be that we edit the syslinux.cfg and append more entries.  A little bit more complicated would be to just have a simple “top-level” syslinux.cfg which uses CONFIG directives to load the additional config files.  Third would be a com32 module to iterate and set up the menu items automatically.  I lean towards the second, at least for at first unless someone is super-motivated to write a com32 module

3. How to know the new directory

   There are multiple places scattered that have hard-coded looking for LiveOS.  There’s the initrd, there’s the livesys initscript and there’s livecd-iso-to-disk/liveusb-creator.  While we could add a kernel command line option and go and change each of these to set it/respect it, it feels like maybe the less general solution.  Maybe it’s just that we should always have livelabel= available so that we can use it other places? 

Of these, I’m especially not sold with the last question and would love to see some thoughts or ideas from others. From there, it should be pretty straight-forward to implement so that we can have everything in place for Fedora 11 Beta

On a related note — I wonder if there’s value in moving the livesys initscript from being based in the live image kickstart config to being provided by a package (most obviously, initscripts)

Fedora livecd

The rumours of my death are largely unfounded.  I’ve just been either busy working or trying to relax while not on a computer since this is as much of a “break” as I get.

I have, though, done various updates to twitter and identi.ca if you have some obsessive need to know what I’ve been doing.  It hasn’t been that exciting, though.  Basically boils down to the following relatively short list

• Went cross-country skiing a couple of times.  With the very wintry weather we’ve had thus far this winter, it’s been something good to be able to get outside and do as it hasn’t exactly been ideal biking weather
• FUDCon F11 was held in Cambridge at MIT.  Since it was in E51 and I knew where things were, I spent a fair bit of time running around.  I had some good conversations, but didn’t give any presentations and didn’t really get any hacking done with the hackfest
• The SDM 09s have started and I helped some with their first design challenge.  Was fun to watch and they seem a good bunch
• Have been trying to read a fair bit and so made good progress on my book backlog.  Still hoping to finish that before classes start back up
• Some poking and prodding in the hopes of getting Fedora 11 alpha out the door in a semi-decent shape
• More work on the new initramfs tooling, although it’s making slower progress than I’d really like
• Getting extra sleep

Fedora, Life, Livejournal Imports, MIT SDM fedora, fudcon, fudconboston2009, life, sdm

As davej was alluding to, we've started trying to make progress on a new initramfs infrastructure that can be used across distributions instead of just being done for a single distribution. Thus far, the code is fairly early and proof-of-concept-y, but I can successfully boot root partitions, root on LVM or root on encrypted LVM. The next step is to clean up the build side so that I can switch to using it with my laptop. I wanted to go ahead and get the code out first, though.

The majority of the ideas behind the code are that we want to use the same tools and utilities that exist on the booted system (so regular bash, regular udev, no nash, no statically linked nonsense, no klibc) and also that we want to not have the initramfs as a slow-down. The latter means that we run pretty much everything off of udev rules right now so that as soon as the devices are available, we mount and switch into the rootfs.

So go ahead 'git clone git://fedorapeople.org/~katzj/dracut.git' and read the README, HACKING and TODO files. Also sent to lkml to get the mailing list started. More hands more than welcome…

Fedora, Livejournal Imports dracut, fedora

At this point, the semester is almost entirely over. While I still have one day of each class left, pretty much every assignment is done and turned in. Only have to finish up the principles assignment for System Architecture and that's mostly a matter of sitting down and throwing some together from the notes that I've got from the semester.

Overall, it's been a good semester. The workload ended up being a bit higher than I expected, but it was probably what I should have thought. I knew that System Architecture was going to be time-consuming, but it was still more so than I thought. Similarly, Project Management ended up requiring more time both for the homeworks and the project than I really expected from the outset.

Those along with working to get all of the Fedora 10 bits working on the OLPC meant that it was just a very busy semester. But, now it's actually the time when I get nearly two monhs to relax and “just” work. Well, and I also am hoping to try to get some progress underway for my thesis so that I don't have to do it all while juggling classes also. It should still be a good sort of break, though. And then, it's on to the spring semester. Which I still need to figure out what I'm going to take — suggestions welcome

Fedora, Livejournal Imports, MIT SDM fedora, olpc, sdm

For some reason, the end of this semester seems to be coming early this time around. Although the end of classes isn't until the middle of December, it seems that pretty much everything is due before Thanksgiving. Which, coupled with trying to get Fedora 10 out the door is going to make the next few weeks a pile of pain.

So if the updates from me seem sparse, that's why. And then of course, to make things even more fun, I came down with something the end of last week which I haven't quite managed to completely shake. Although at this point, it might just be my usual congestion for this time of year.

Fedora, Life, Livejournal Imports, MIT SDM fedora, life, sdm