LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
DistributionsNews and Editorials Vancouver goes to Helsinki The Debian release team meeting held in Vancouver in March spawned a proposal for creating quality requirements for Debian ports to trim the herd of supported architectures. That proposal, not surprisingly, generated quite a bit of heated discussion among Debian developers.Wouter Verhelst called for a follow-up meeting at Debconf5 in Helsinki, and has submitted a report covering the discussion at the meeting. According to Verhelst's report, several points from the Vancouver proposal were discussed. The first of the "problematic items" is the requirement that "an architecture must be publicly available to buy new." This was clarified to mean "new hardware which, as of yet, is only available under NDA, or to avoid things such as a Vax port of Debian" and not to be applied retroactively to existing ports. Since it would be difficult, at best, to provide widespread access to hardware that requires Debian developers to sign an NDA, it seems a very reasonable requirement. The next sticking point is the requirement that "any architecture needs to be able to keep up with unstable by using only two buildd machines." Unfortunately, Verhelst reports that "we didn't reach an agreement; in the end, we decided to move on." There will be more debate, but the requirement will remain in the meantime. Another topic of discussion in Helsinki was the veto powers that would be given to the Debian System Administrators (DSA), Release Team and Security Team. Those teams would be able to veto an architecture if it would have an adverse impact on the quality of the release and/or the length of the release cycle. There are still those who object to the "arbitrary" veto powers, but Verhelst responds that if it's abused, the team vetoing the release can be overridden:
That's why we introduced the rule that if one of the teams decides to use their veto power, they /have/ to explain themselves. If someone then posts something like "I've had a fight with <foo> the other night, so I'm going to make him feel sorry for it and drop his port", I suspect requests will go to the DPL to please replace this person. Or if someone posts a rationale to drop a port consisting of arguments each of which are completely and utterly false, that a discussion will follow, pointing this out, and (ultimately, if the team isn't convinced) a GR to overrule the decision.
We also asked Debian Project Leader Branden Robinson for input on Helsinki meeting, and whether the veto power was necessary and how to make it more acceptable. Robinson said he was "equivocal about it."
On the one hand, certain administrative issues do tend to get concentrated in particular roles, and I can empathize with how it can feel unfair to a person in such a role to be expected to do certain kinds of work to ensure a port is sustainable because no one else is bothering. In many situations, to do your nominally-appointed task A, you have to also do tasks B, C, and D, and if the developers in general aren't doing them, even if they should, the "privilege" falls upon you. Because if you don't, the work won't get done and then you *will* be accused of sabotaging or ditching the port.
At the same time, the concerns of the developers in general are legitimate. We *should* be cognizant of concentrations of privilege and power, because then we render ourselves susceptible to decision-making based on personality rather than consensus. Again, Biella Coleman's paper describes how the Debian Project is culturally uncomfortable with such a possibility. I think the only real long-term solution to these problems is to decentralize our processes as much as we can. This is difficult in part because there is much expert knowledge locked up in the heads of people who either don't have the time or the inclination to serve as mentors or documentation-writers. As Coleman describes in Chapter 6 of her dissertation, there is a strain of the meritocratic geek philosophy which holds that self-education is the only legitimate avenue to exercise of authority. In my view, while it's certainly laudable to encourage people to grapple with challenging and unfamiliar code, material, or concepts on their own, this process demonstrably leads to the entrenchment of elites. The "98 percent rule," requiring a port to compile 98 percent of the archive's source, is also generating quite a bit of discussion. A look at the build daemon statistics can be instructive in seeing how well each port is doing in terms of building packages. However, there's little point in worrying about those statistics right now while things are still undergoing rapid development, as Steve Langasek points out:
The result is that it will be rather difficult for a while to *measure* how well ports are keeping up, so there's probably just no sense in trying to until things cool down in unstable.
In his report, Verhelst suggests that the Vancouver proposal was not intended to "kill off" some of the Debian architectures. Langasek, who was not at the Helsinki meeting, clarified that the intention of the Vancouver proposal was "motivated by a concern that the absolute count of release architectures in Debian is too high to be sustainable." We asked Robinson if it was likely that any ports would be dropped from Etch, and he replied that "it's possible that a currently supported architecture will be dropped. I don't yet consider it likely. I think the reason for dropping an architecture for Etch, if it happens, will likely have to do with build daemon failures for that architecture." It would appear that the Helsinki meeting has moved the ball forward a bit in terms of developing a set of release criteria for Debian ports. However, it's also clear that there will be a great deal more discussion before a final set of criteria is adopted. Obviously, no matter what the final language, it will not make everyone in the Debian community happy. However, we think that the Vancouver proposal is a good start towards making the Debian release process faster and more predictable.
New Releases Asianux 2.0 released Chinese Red Flag Software Co., Ltd., Japanese MIRACLE LINUX Corp. and Korean Haansoft Inc. have announced the release of Asiaunx 2.0. "Asianux2.0 is co-developed by Red Flag Software, MIRACLE LINUX and Haansoft in Beijing. Based on this common platform, local branding products, including 'Red Flag DC Server 5.0', 'MIRACLE LINUX V4.0' and 'Haansoft Linux 2006 Server & Server 64' will be released and sold in Chinese, Japanese and Korean market. These three products are 100% identical in OS level and provide customers with more local value-added application level features."
BLAG39999.20000 Released BLAG Linux and GNU has announced (click below) an alpha release of the forthcoming BLAG40000. BLAG39999.20000 (dents) is based on Fedora Core 4 plus updates, adds apps from Dag, Freshrpms, NewRPMS, and includes custom packages.
Distribution News Fedora: RFC: X.Org X11 modularization project - rpm package driver naming Fedora has begun work on X.Org X11 modularization, and they are in the process of packaging the video and input drivers. The modularized X.Org X11R7 will make it much easier for an individual driver to be updated without having to release the entire 150Mb monolithic X release. Click below to see the proposed naming conventions. "Interested Fedora Core, Fedora Extras, or community developers who have an opinion about the X.Org modular package naming conventions, or who just want to provide feedback concerning the above proposal, are encouraged to respond to this RFC on or before Monday August 29th if possible."
Debian news Joerg Jaspert explains what he has been doing with the NEW queue. "NEW checking is about three things. In order of priority: trying to keep the archive legal, trying to keep the package namespace sane, and trying to reduce the number of bugs in Debian. Not all QA issues will be noticed; we don't test packages, but we do look through them and note problems that jump out at us. Sometimes that'll result in a bug, sometimes it will result in an email, sometimes it will result in a REJECT, depending on how serious the issue seems."Andreas Barth looks at the status of various package transition efforts. "we currently have a couple (or rather: way too many) transitions already ongoing. Please, don't upload shlib bumps or lib renamings unless required by one of these transitions." There is now a Debian GNU/kFreeBSD i386 machine available to Debian developers. "The machine name is "io.debian.net". It was kindly donated by Aurelien Jarno and is hosted by "ETH Zurich, Department of Physics". We wish to thank them for their contribution to the GNU/kFreeBSD development." The next Bug Squashing Party will be held September 2 - 4, 2005. "Coordination will happen over IRC channel #debian-bugs on irc.debian.org as usual." Here are some Results of the meeting in Helsinki about the Vancouver proposal.
New Distributions ELE Live CD ELE is a bootable Live CD Linux distribution with focus on privacy related software. It is based on Damn Small Linux and aims to be as small as possible. The current version is 0.0.2, released last March.
Mupper Mupper is a rescue-CD project for the PegasosPPC. It is based on Gentoo Linux and contains various tools like parted, midnight-commander and support for various filesystems including FAT, VFAT, ReiserFS, XFS and EXT3. The live CD also includes some network tools such as snort and tcpdump. Mupper joins the list at version 0.3 which was released August 28, 2005.
Distribution Newsletters Debian Weekly News The Debian Weekly News for August 30, 2005 is out. This issue looks at reasons to use Debian and an overview of some Debian derivatives, Debian in China, requirements for NEW, a new Debian GNU/kFreeBSD development machine, package transitions, and several other topics.
Fedora Weekly News, Issue 11 The latest Fedora Weekly News looks at a Guide to Managing Software with Yum, the availability of Yum Extender 0.42-03, Setup your wireless client at home, Secure your desktop PC, Using yum localinstall packagename, Why no hat? Here's why, Fedora Myths - New Fedora Wiki Page, New CSS on fedoraproject.org, and several other topics.
Gentoo Weekly Newsletter The Gentoo Weekly Newsletter for the week of August 29, 2005 covers Gentoo documentation updates, Swedish rescue CD for PegasosPPC, and several other topics.
DistroWatch Weekly, Issue 115 The DistroWatch Weekly for August 29, 2005 is out. "Plenty of media hype about Asianux last week, but is the project worth the attention? We doubt it and we'll tell you why. We have not done a book review before, but we couldn't resist one in this edition after we found ourselves infatuated with Dru Lavigne's BSD Hacks, an excellent collection of superb tips for administering BSD operating systems. Also in this issue: an interview with Jay Klepacs, the founder and lead developer of aLinux, and the usual regular departments."
Package updates Fedora updates Updates for Fedora Core 4: audit (bug fix), openoffice (adds a README to he_IL dictionary), libsoup (fix for NTLM authentication), selinux-policy-targeted (bump for FC4), policycoreutils (fixes for fix files), xen (upgrade to a newer version of the upstream xen-unstable), evince (update to 0.4.0 and merge some fixes from devel), poppler (a PDF rendering library).Updates for Fedora Core 3: freeradius (security updates), libsoup (fix for NTLM authentication), evolution-connector (patch for PDA synchronization), epiphany (update to 1.4.9).
Slackware updates Slackware Linux has a lengthy changelog notice (click below) for August 30, including a number of upgrades, new packages in testing, and security fixes.
Miscellaneous Articles MEPIS: the miniature monster of Morgantown, West Virginia (Mad Penguin) Mad Penguin talks with Warren Woodford, creator of MEPIS. "In this interview, Warren explains the secret to his distro's rapid and widespread proliferation. Give desktop customers what they want: a simple, reliable set of applications that are easy to acquire, install, and use. Give it away for free. Always. Show respect to the command-line community who created the base packages in the first place. Join the Debian Common Core Alliance, and play nicely in the sand box with them."
Distribution reviews First look at aLinux 12.5 (MadPenguin) Mad Penguin has a review of aLinux. "From what it looked like, every available 'look and feel' option in KDE was turned on by default, and from what I could tell.. a few more were added to the mix. The style appears to be Linspire's 'Crystal Clear' and it looks good, but the rest put it over the top. As everyone who frequents our site probably knows, I'm a real sucker for a good looking Linux desktop, but this is a bit too much for me. There is so much going on here that it is almost to the point of being totally distracting."
Review: VidaLinux 1.2 (Linux.com) Linux.com takes a look at VidaLinux. "VidaLinux is great for people who want to ease into a Gentoo Linux environment and don't want to do a lot of typing and surrender a lot of their time for the installation. You start out with a working desktop environment and can work from there -- and if you screw everything up beyond your ability to repair, you can more quickly reinstall VidaLinux than plain Gentoo. Seekers of user-friendly desktop distros, beware: VidaLinux 1.2 probably isn't for you."
Page editor: Rebecca Sobol |
|||||||||||