Scott Dier piped up to say: It would be really, really nice if the d-i preseeding stuff could make it into warty, even if its unsupported. It's the first blocker (the other being this odd i915/hwclock bug) that I'm seriously worried about here -- I can deal with installing some machines manually but eventually this will catch up to me within weeks. What are the chances of seeing d-i preseeding soon? If not, I'm most likely going to have to make do with sarge here -- I didn't expect that Joey was already working on the problem and had something working, serves me right for not paying attention to the -boot mailing list.

Colin Watson, the brain and brawn behind Ubuntu's modified D-I work, threw his feelings on the matter out and deferred to Matt Zimmerman and Jeff Waugh for the final decision:

Jeff Waugh donned his release managers' hat and took a position saying, I'm not convinced it's a huge win, plus it's a big freeze break with no major bug rationale. We're being loose for WartyWarthog, but we have to put the brakes on and concentrate on getting bugs fixed and our release out the door. This is not a release critical feature, so I'm inclind to say "NO!". Folks seemed to think that was fair enough.

Emil Oppeln-Bronikowski sent a message to the Ubuntu-devel list about Warty support for the Pegasos PowerPC blatform. Emil first introduced the Pegasos with some background information:

Matt Zimmerman replied and said, Since we already support the CPU architecture, it should only be a matter of driver support in order for Ubuntu to run on this system (it shouldn't require a separate port). There is already some Pegasos-specific code in the kernel, though I don't know how complete it is. Have you tried installing Ubuntu on such a machine yet?

Colin Watson added that, I'm apparently going to be getting a Pegasos reasonably soon. Making the powerpc port run on it won't happen for Warty, but assuming it doesn't take too much effort away from other things I should imagine it'll be possible later.

Emil Oppeln-Bronikowski asked if he could go ahead and create a Polish info site for Ubuntu. In his words, it would be introduction to what Ubuntu is, why it's good, where to find it, where to look when you're stuck with something, some screenshots. Just a quick information that polish Linux users would read, think about it and download ISO.

Matt Zimmerman who weighed in the issue was very happy about this saying, by all means, proceed. In the future, we will have a facility to provide localized versions of the official Ubuntu site; perhaps at that time, your efforts can be integrated into the main site.

Others who are interested in creating this sort of information about Ubuntu in non-English languages are welcome to proceed. It might be a good idea to throw a message out on the relevant lists though so folks don't duplicate work. The right place seems to be the Ubuntu Translators email list at: http://lists.ubuntu.com/archives/ubuntu-translators/

Jason Pearce pointed out that there was a security update for Mozilla Firefox on the ubuntu-devel mailing list. The update is detailed here: http://www.mozilla.org/press/mozilla-2004-10-01-02.html. Jason added that, This does bring up an interesting issue though. Firefox isn't able to install its own updates on Ubuntu or on most any Linux system when a user is running Firefox I would imagine. I am of course running on the assumption that Firefox wants to update it's executable files (correct me if I'm wrong). To work this would either require the Firefox browser to be run as root or to be sudo savvy. Either way the feature is questionable on any Linux system since it very likely wants to update files that should only be touched by the OS package manager. Should this feature be compiled out? Or maybe just disabled by default?

Matt Zimmerman replied to Jason saying that the security bug, doesn't sound particularly severe, but it should certainly be fixed before the release. Please file a bug in bugzilla. Matt also added that, Firefox's internal update feature should probably be disabled in Ubuntu. Please file a bug about that as well. Jeff Waugh gave a little more information on the situation saying, Unless it was overlooked with our upgrade to PR1, the internal update feature is disabled in Debian, and has not been enabled on any of my installs thus far.

Several threads on several lists talked about the promise of a new Documentation team. This is great news. Benjamin Edwards said: There have been a few people talking about documentation recently. This is both regarding online collaborative documentation such as FAQ/hardware compatibility and user/hot-to type things. I think ubuntu-doc@lists.ubuntu.org would be great, or even essential. What do people think?

At the moment, the best tactic is to use ubuntu-devel but to prefix messages with a [doc] tag. Once this gets overly annoying and the need for a new list is proven, a list will be created. This will be the process for all new teams.

The thread, and others elsewhere, ranged over a number of issues. Formats were one sticky point although there seemed to be something resembling consensus around using DocBook for documentation wherever possible.

In another documentation related thread, Sivan Green pointed out some docs he'd be working on:

Elsewhere, Sergio Blanco Cuaresma pointed a mini guide in Spanish that is available here: http://www.marblestation.com/blog/index.php?p=3D206 and http://www.gpltarragona.org/node/view/300.

ubuntu-users saw half a dozen threads this week on ndiswrapper. Because, some vendors do not release specifications of the hardware or provide a Linux driver for their wireless network cards, the Ndis wrapper project was created to provides a Linux kernel module that loads and runs Ndis (Windows network driver API) drivers supplied by the vendors.

Mid-way through the week, ndiswrapper was added into Ubuntu. Todd Maynard noticed this and asked, Does this mean that now from a fresh install I'll be able to install ndiswrapper from synaptic, and let it worry about all of the kernel header/source dependencies? Matt Zimmerman confirmed that this was the case. Matt also pointed out that the name of the package is ndiswrapper-utils.

Andre Kuntze wrote up the whole process of getting this up and running in a HOWTO document that is now available on the Ubuntu website at: http://www.ubuntulinux.org/support/documentation/howto/helpcenterhowto.2004-10-07.7773155363

John Harvey posted a message to Ubuntu-users about promoting Ubuntu saying:

John Levin responded suggesting that www.spreadfirefox.com may be a source of good inspiration.

It sounds like the sort of stuff John (and John) are doing now is exactly what Ubuntu needs. Canonical is doing what it can to help by providing CDs and the like but real person-to-person word-of-mouth style activism is what is going to both build the distribution and spread it around. A responsive, committed, and involved community is the key to Ubuntu's success and it appears to me that we've done more to create this in a short period of time than almost any distribution I've seen anywhere before.

In an announcement that was delayed a few days, Matt Zimmerman unveiled the Ubuntu Preview Live CD:

Oliver Grawert threw out a quick suggestion onto the lists saying: why not run debconf by default in gnome mode, it integrates pretty fine with synaptic and the desktop and would only require gtk2-perl in main. if it's configured for gnome, but run on a console it falls back to curses. wouldn't that fit in the "non commandline policy"?

Colin Watson replied saying, This will probably be part of the more general graphical installer effort, which is currently targeted at Hoary. I think it's a bit late for Warty now to get any bugs shaken out.

An anonymous poster said, I Read some weeks ago a interview with the Yopper Distro lead and he say that one thing that make Yopper faster than other distros is that they uses prelinked binaries in most apps. So, why don't do the same thing on debian & ubuntu?

Scott James Remnant did some benchmarks to see what the real performance benefits were:

descent scott% LD_DEBUG=statistics /lib/tls/i686/cmov/ld-linux.so.2 /usr/bin/gedit
     19055:
     19055:     runtime linker statistics:
     19055:       total startup time in dynamic loader: 95427223 clock cycles
     19055:                 time needed for relocation: 87261064 clock cycles (91.4%)
     19055:                      number of relocations: 2720
     19055:           number of relocations from cache: 2599
     19055:                time needed to load objects: 7556171 clock cycles (7.9%)
     19055:
     19055:     runtime linker statistics:
     19055:                final number of relocations: 9238
     19055:     final number of relocations from cache: 3511

descent scott% LD_DEBUG=statistics /lib/tls/i686/cmov/ld-linux.so.2 /usr/bin/gedit
     19314:
     19314:     runtime linker statistics:
     19314:       total startup time in dynamic loader: 90071299 clock cycles
     19314:                 time needed for relocation: 82785218 clock cycles (91.9%)
     19314:                      number of relocations: 2720
     19314:           number of relocations from cache: 2599
     19314:                time needed to load objects: 6686188 clock cycles (7.4%)
     19314:
     19314:     runtime linker statistics:
     19314:                final number of relocations: 9279
     19314:     final number of relocations from cache: 3511

For those whose mind gets a little confused buy the above data (myself included), the basic results are that they are not significantly different.

Orlando Fiol asked, But, why don't have all packages prelinked by default if that will make the apps faster and the normal (and/or newbie) user don't should have to do this by hand? Scott James Remnant explained that, Every package would have to be re-prelinked and built every time any new package was uploaded; it's simply not possible.

Benjamin Mako Hill pointed out that: