Thanks to everyone for the feedback on PPC usage.
At this week’s (public IRC) Fedora Board meeting, Seth had kindly put the issue up for discussion and since it was a public meeting, I took part as well. Now the first question that might come to mind is “Why does the Board care / make the decision?”. And the reason is that it was the Board that originally voted to keep PPC as a primary arch until there was another functional secondary arch. Now that we’re two years later and there’s still not another functional secondary arch, I think that the topic was worth revisiting.
The discussion ended up being somewhat lively, but to me there were just a few key points. On the side of requiring PPC kept as primary, the argument seemed to mostly be that by going to secondary, PPC as an arch in Fedora would not be successful. One stated reason was the timeframe. So there was a proposal for keeping the requirement in place until either a secondary arch is up and running or some time limit (six months? a year?) was hit. The other side is that it’s been two years, what difference is a known six month time horizon going to make?
In the end, the Board voted and decided that from the Board level, PPC is no longer required to be a primary arch. That does not mean that PPC is now automatically a secondary arch.
So, what’s next? The next step is that I am proposing to FESCo that they consider a proposal to have PPC become a secondary arch for Fedora 12. And in doing so, put out a call for someone to lead a PPC secondary arch group. That would entail the work in keeping builders running, creating test releases, getting testing, etc. And then also being the person responsible for getting the release out and calling it done.
By making PPC a secondary arch, there are a few tangible benefits.
- Likely less build time for packages, rawhide, etc so that hopefully development can move a little faster
- Less last-minute scrambles to fix the PPC-specific distribution issue (whether it be installing on some platform or fitting on the DVD)
- More people caring about the secondary architecture process and thus hopefully helping it accelerate.
There are, though, also some risks and downsides. I’ll list them as well, but with my refutations
- It’s possible we could not have everything in place for a Fedora 12 PPC release. While I freely admit that this is a concern, I think that this is a concern no matter when we move PPC to be a secondary arch and I actually see the argument here getting stronger over time as the number of PPC users decrease as old Macs die.
- We may lose some portability testing in builds. Also, true. Hopefully the build infrastructure for secondary arches is far enough along that those can be reported still.
Thoughts, comments, etc appreciated as always
Warning: Something of a rant ahead… I considered not posting it, but am curious as to the responses I’ll get
Okay, I know I’ve said this before, but I’m wondering why we continue with the illusion that PPC is a “primary” arch for Fedora rather than a secondary. At one point, the argument was that we were waiting until there was another viable secondary arch and then ppc would become one as well. The better part of four releases later (as I’m pretty sure I was having this discussion before Fedora 7’s release), we’re still in the same place. Maybe having ppc as a secondary arch would help to make that process smoother as those that care could help to improve the process.
As it stands, we instead say out of one side of our mouth that ppc is a primary arch but we have regularly dropped it from being included in a major development milestone, livecds were broken for 18 months (!), ps3 support is regularly broken in one way or another (and ps3 is one of the touted “most valuable” ppc platforms) and the majority of the bugs against ppc I see filed are either from jlaska or the IBM bugzilla proxy.
In any case, Fedora 11 will see restored the ability to create live images on ppc after someone reported it and Josh Boyer was kind enough to sit down and send me a patch on top of the obvious things based on the original report. Which was the original thing that got me thinking on this topic again.
But to go a step further — are you using Fedora on a ppc? If so, what kind of hardware and in what sort of use case? Inquiring minds, or at least I, want to know. Drop me a line in the comments.
Ten years ago today, msw made the very first commit to anaconda. A graphical installer for Red Hat Linux. A tool to make Linux more accessible to the masses by making it easier to install than the (at the time) text based newt installer.
Today, nearly 19000 commits later, the progress continues. And in one of those somewhat expected twists, we’re actually now deprecating the (interactive) text mode and stripping it to its very core. The graphical install has succeeded, I think, beyond what anyone would have expected.
That said, hopefully I won’t be writing a post like this in another ten years
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.
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?
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.
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!
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. :-/
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
- 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.
- 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
- 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)
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