Tag Archives: fedora

Oh, and some links

Oh, and some links if you have a laptop and want to help out…

  • Torrent site — you can grab the latest live image from here. Testing from a live image is a great way to help ensure that you don't have changes that you've made locally to “fix” things up without getting the fixes into packages.
  • Quirk creation page — Hughsie's helpful site will help you through getting quirks that you can submit both for fixing suspend/resume on your machine as well as for keycodes. Send them to the upstream hal list so that they can be included there and then we'll just ensure that we have a very recent snapshot when finalizing the release
  • Bugzilla — and for the things you can't resolve with quirks, it's probably worth filing bugs. Don't count on the fact that someone else has the same machine as you and will file the problem. The only way that bugs are known is when they're filed

Fedora 8 and Laptops

One of the features that has been on the feature list for Fedora 8 has been the pretty vague bullet point of “Improved Laptop Support”. And a lot of good stuff has gone on under the covers, but to someone tracking the development tree on a daily basis, not much of it is really that obvious. To help ensure that we have improved and also to look for any of the little obvious gaps which needed jumping, I've spent a lot of the past few days doing nothing but testing out a current rawhide live image on a wide variety of laptops. And the nice thing is that there are a lot of things that are going to be rocking for Fedora 8.

One of the big areas that people should immediately notice a difference in Fedora 8 is wireless drivers. Fedora 7 made some first steps here with the inclusion of firmware for the ipw2x00 and iwl3945 chips, but the iwl3945 driver was a bit flakey at release time. Fedora 8 adds to those also with support for the new iwl4965 wireless as well as including drivers and firmware for a variety of pci and usb cards. The big wireless drivers still outstanding are for Broadcom and Atheros. Broadcom actually has a working driver and once you download the firmware and extract it with b43-fwcutter, it works great — this isn't ideal, though, so hopefully we can work with Broadcom to get a redistributable firmware image for the future. Atheros chipsets, unfortunately, aren't in as good of shape… but with work getting underway on the ath5k driver, I'm hopeful that we'll be able to support these chips with a legal and open driver for future releases. And as an added plus, most of these drivers have now been merged for 2.6.24 so that we don't have to carry the patches for the future.

Another area that should have some nice improvements is handling for various multimedia keys. Some efforts by hughsie, hadess, and others, there's now a standard way of both getting key events mapped from the scancode to the keymap via hal quirks and we also set up the default shortcuts in GNOME to use the normal media keys in X. The final piece was setting up our default keyboard layout to include the media keys. I've been fixing up laptops to have the right scancode mappings in hal, and those should be included in hal-info that we include in Fedora 8. Also, I've sent the relevant kernel patch upstream so that Thinkpad volume buttons send keypress events (imagine that!) so that Luis's bug can be fixed.. although the patch is meeting some bizarre and not entirely fathomable resistance upstream (you want to create a whole new way to send events that are keypresses? *boggle*)

A final area that should have some improvement is suspend or more importantly, resume. The database of quirks continues to grow based on the infrastructure that was present in Fedora 7. I was happily surprised with how well this is working across a variety of machines. The biggest area of shortcomings right now is that laptops with nVidia graphics don't seem to want to resume correctly (with the nv driver). This has worked in the past, though, so I'm hopeful that we can get something to at least work in some of the cases.

But overall, looking pretty good. I've been keeping track of what I've tested on the wiki and will continue to update and expand it leading up to Fedora 8.

Click, click, click

What's that? Oh yeah, it's the sound that my laptop hard drive started making yesterday. *sigh* Just to add to the fun, no errors had been shown by smart and even today after the drive wouldn't boot at all, smartctl didn't show any errors with a short self-test. The long one eventually did, though. Luckily, the drive was still alive enough yesterday that I could pull a last ditch backup of anything that I didn't happen to have. Now I just get to wait for a new hard drive to come in. While waiting for that, I'm just using one of the random QA laptops with a USB key with a live image of my own creation. It's actually a pretty reasonable environment, especially given that I hacked in a mount of an encrypted /home so that I can have bookmarks and some persistent storage. Still not quite the same as running on my normal environment, although it really does work shockingly well. Would be good to get to where doing this isn't a big deal — definitely would be something that I think a lot of people could be interested in.

Otherwise, been busy working on a variety of different things. Have most of the changes in place so that anaconda can create its second stage images using yum and a little bit of ldd smarts rather than doing rpm2cpio on a list of packages plus a keep list of files. I've also spent a fair bit of time working on getting the presto code into a bit better shape so that we can hopefully include it and enable it by default for Fedora 8. Also continue to do miscellaneous fixes across things that I'm running across just in my regular running of the rawhide tree. I think I've most accurately described my current working habits as “acts of random” 🙂

And then, of course, I've been riding a lot. The weather in the Boston area continues to be gorgeous — there have been some warm days and some rainy days, but overall, there's really nothing at all to complain about. I've been trying to get in 100-120 miles a weekend so that I can be prepared for the Seacoast Safari which I'm doing in a few weeks. It's a ride along the Massachusetts, New Hampshire and Maine coasts to raise money for Cystic Fibrosis. Should be a fun ride, although I really need to get on with my fund-raising a little bit better.

But, now to try and see what I can get done for the evening.

Fedora 7 Test 2

My posting these days seems mostly around when a notable Fedora event happens. Which, it's that time again I guess. Another month, another Fedora test release. The package set on the media looks a bit more familiar this time as opposed to the desktop only run with test1. Also, more of the features are starting to fall into place and feel closer to feature complete. With the recent schedule change, we have a little bit more time to try to finish up some final loose ends. In test2, some of the things to check out include:

  • Live CD continues to move along. The big changes from the live CD in test1 are that we're using isolinux instead of grub for booting and more of the PATA cd drive bits should work. This is definitely an area that could stand to have more testing, though. So download it and try it out. And the excuse of “I can't blow away my machine” just doesn't apply for the live CD unless you try out the install feature (which you can find under Applications->System->Install to hard drive)
  • Fast user switching has started to land in Fedora. This will be great for people who share the use of a machine with someone else as they can have separate users and not have to log out. The bits have all been present, but things are all being integrated so that it can Just Work ™ out of the box. davidz has been doing a lot of work here and it's coming along quite nicely.
  • Lots of yum changes. The big thing has been getting depsolving done without requiring headers and that's been a bit more work than I think anyone expected. By doing this, we should be able to make some nice speed benefits by just being a little bit smarter on what data we use. And we don't have to download headers. Thus far, though, the focus has been on correctness. So speed is to come.
  • The start of supporting media for pirut, etc. This was blocked a bit by the fact that headers were used for depsolving because you really don't want to prompt the user to change CDs 20 times as you try to resolve deps. This is in test2, but requires a little bit of manual setup right now; basically just add a mediaid= line to your repo config with the first line from the .discinfo file of your CD. This manual step should hopefully go away for test3
  • More support for more virtualization. The virtualization world isn't just Xen anymore. So, libvirt and virt-manager now also support qemu and kvm. This is pretty nice for a user and will continue to get better.
  • Other stuff I'm not thinking of. It's hard to keep up with everything these days…

Nickel a spin…

One of the big things that we're trying to get to with Fedora 7 is making it a lot easier for people to take Fedora and create a version (a “spin”) that's suited better for their particular environment. This has a lot of applications for different types of environments. One of the downsides is that it raises the pretty large questions around what spins we should provide by default for download.

The original thinking here was that we would create a desktop oriented spin, a server spin and a KDE spin. Heated discussions have ensued since then. The questions have revolved around a few big things:

Desktop spin
As is probably evident from above, it's been the plan that the “desktop” spin would try to provide a pretty similar set of functionality to what you have historically gotten with a default install of Fedora. This then includes GNOME, OpenOffice.org, support for lots of languages, etc. With all of this, we pretty quickly get to 3 CDs.

The first question that then comes up is “how do you get it smaller?”. Unfortunately, the answer really is that you have to cut functionality. Either support for large chunks of the world or something like OpenOffice.org.

The second question is always “what about doing development”? The spin as provided above doesn't have any of the development tools (gcc, etc) that one might want or any of the development libraries or headers. Adding the development bits to this spin isn't that big of a deal, though — most users are likely to get a DVD iso as opposed to CDs so adding an additional CD worth of size isn't a huge burden.

In addition to just the spin described here, we are planning to provide a Live CD that maps pretty closely to the default install of this spin. Some of the functionality will be reduced for the fitting on a CD, but what can be done will be. That then can help the people for whom the additional CD of development is a problem.

Server spin
The server spin is perhaps even more contentious. There's not a clear answer if the server spin should be “bare minimal to get a shell and run yum” or if we want to provide something which is more usable someone wanting to set up their first Linux based server. The latter implies some amount of graphical environment and tools for configuration. The graphical environment is also somewhat for parts of the world which don't use a roughly Latin alphabet that they can actually read what's being printed on the screen. The other wrinkle with a server specific spin is the lifetime — Fedora releases are maintained for a far shorter period of time than a lot of people who run servers will want. How do we deal with these?

What do we want to solve?
By FUDCon (and especially after the Fedora Server spin discussion on Friday), it was starting to become clear that our original idea of doing a desktop, a KDE and a server spin wasn't going to do a good job of meeting the needs and desires of our users. So we stepped back to think about what we're concretely trying to achieve. We came to a pretty short list.

  1. Must provide a way for people to do their own custom versions including packages from all of the Fedora universe.
  2. Want to provide at least one installable “single CD Fedora” to help in parts of the world with less bandwidth
  3. Need to provide a way to install via media for the following cases:
    • Desktop environment
    • Developer use
    • Simple LAMP server
  4. Try to be as little of a burden on our mirror and testing infrastructure as possible.

We're well on our way with the first point and a lot of what's from here is documentation, cleaning up of error handling and just providing examples for people. We still have a pending action item to provide clear guidance on what you can call such a thing.

The second is actually something which is pretty well handled with Live CD. The idea of a single installable CD for the desktop is still appealing, but feels less and less doable as the set of expected stuff grows. The Live CD, though, can have a few different constraints get us there. And with the work that's been done so that you can install from the Live CD using anaconda,

The fourth is the really tricky one. While tools such as jigdo help here, they inherently make things more fragile and also limit the platform you can use for downloading isos. Also, the additional testing is there for every additional media set, no matter what.

The Fedora 7 Proposed Solution
Given all of the above, we think that the best idea for Fedora 7 might be to provide the following as the official, release-day Fedora 7 spins:

  • Fedora 7 Desktop LiveCD
  • Fedora 7 KDE LiveCD (to be driven by Rex Dieter and the Fedora KDE community)
  • Fedora 7 DVD. With everything for desktop, development and “mainstream” server tasks. This ends up replacing what was previously Fedora Core. The current thinking is that this would be provided as a DVD iso only.
  • Fedora 7 Everything. 2+ DVDs. More bits than you can shake a stick at. Not available on the mirrors; bittorrent only. Hopefully can share the first disc with the Fedora 7 DVD.
  • Make your own Fedora 7 step-by-step guide. This is important to help ensure that people understand and can make their own custom spins.

The question now is “what do people think of this?” In a lot of it's the easy way out — we avoid answering the hard questions just by bailing. At the same time, it gives us more time to have discussions about those hard problems as well as making it so that the discussions can occur with people really trying things out. Instead of saying “I want everything to fit on one CD”, people can use pungi and try to actually get to one CD. Or two. Or whatever. And then come to the discussion with facts as opposed to a vague idea.

Have comments? Leave a comment or use some other smoke signal method of letting me know.