Search Results: "ana"

4 September 2006

Branden Robinson: Update on Debian Security Infrastructure and Personnel

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)

Branden Robinson: Dropping the Soap in the Gulf of Mexico, or: How I Got Cornholed by Continental Airlines

Short version first: those in Oldenburg who are expecting me to arrive at the Bremen airport on Friday afternoon, don't. Expect me on Saturday at 11:10 instead, assuming there are no further setbacks. I got to the Indy airport today in time for my flight, except my flight was going nowhere fast. "No problem," I thought to myself. "I have nearly a three-hour layover in Newark. They can dicker with this flight for quite some time, or I can get switched over to the flight on the commuter jet that Continental also has going to Newark this evening." Silly me. My flight has a "wing indicator light" problem — that's what the gate agents called it, shrewdly deducing that a pilot otherwise has no way of determining whether the lifting surfaces are still attached to the aircraft — that amazingly takes hours to resolve, and the other flight? Well, Continental's headquarters are in Houston, and apparently some of their employees startlingly decided to evacuate their families out of the expected path of Hurricane Rita instead of showing up to work in Indianapolis to be the flight crew. Or something like that. So instead of getting to switch over to the flight that would get me to Newark safely in time to catch my connecting flight to Paris, the airline shunts all those passengers onto my flight. So we take off about 3 hours and five minutes late, and when I land in Newark, there's nothing left of my flight to Paris but wing tip vortices spiraling out over the hypodermic-syringe-strewn New Jersey coast. Apparently airports both in the U.S. and Europe have a problem with flights leaving or arriving in the middle of the night, so the soonest I can leave for Europe is now 1845 on Friday. This means I'll miss nearly a full day of the conference, which I was only going to be at for 2.5 days anyway. Joy. Oh, and they also close down baggage claim at 11pm (or five minutes before you land, whichever comes first), so my checked bag which couldn't make the same flight I couldn't is now being held hostage somewhere in the bowels of Newark Airport while I sleep at the Howard Johnson's in a room that one dare not view in ultraviolet light. Well, technically, this hotel is joint venture with Holiday Inn, an enterprise which no doubt serves the sole purpose of frustrating class-action liability suits by people who contract scabies in the course of their stay. I don't even know if my beloved dismantled Quadra is in better accommodations, or if my machine, tortoise.deadbeast.net, stuffed into a suitcase and crudely protected with towels and masking tape, has been obliterated with patriotic fervor by the TSA, swinging their hammers to pulverize it. I guess I could be in worse places, like Galveston. Any DDs in New York wanna give me a wake-up call in the morning and meet for lunch? (I'm at +1 973 589 1000 x217.) If not, I was thinking I might try to go see the Statue of Liberty in the late morning. I've been in the NYC area twice before but never went to see it. Air travel sucks. Maybe this is the real reason, unadmitted to myself until now, that Contact resonates with me. I can almost forgive Robert Zemeckis for that brown smear he did with Tom Hanks three years before. Then I remember that other brown smear he did with Tom Hanks three years later. Okay, I won't blame Hurricane Rita or even Continental Airlines. I'll blame Robert Zemeckis instead. :-P I'm okay to go... I'm okay to go...

Branden Robinson: On key servers, public keys, errors, and corrections

My previous entry about a fellow developer's GPG key causing nasty spew from gpg on my system provoked an unhappy response. I had hoped to instead stimulate a discussion* of the problem — whether a bug in GPG, a bug in the key servers, or both. From Alexander's explanation, it looks like it's the latter. If a hunk of your key gets corrupted and then submitted to the public key servers, ever, then there's apparently no in-band way of signaling that to those key servers. Apparently you have to contact the humans who administrate the key server and arrange for something approaching divine intervention (in the sense that any large database that has many simultaneous reads and writes going on at all times via defined interfaces really should not have people mucking around with its innards in an ad hoc fashion). Just off the top of my head, it seems like one should be able to submit a GPG-signed copy of one's own entire keyring to the key servers, and have any key signatures within that be regarded as "authoritative", only capable of supersession by another signature bundled in a keyring signed by the keyring's owner. The handling of signatures not in that signed keyring would not change. (It does occur to me, though, that this means that the key servers are susceptible to an annoying attack wherein people can deliberately add corrupt signatures to other people's keys and promptly upload those keys to the public key servers. It would also be easy to automate such an attack. Oy vey. Consequently, it might be worth considering a key-owner-only update model for keyrings on the key servers.) Debian relies heavily on its web of trust, and on the GPG application specifically, and it seems a shame that this problem hasn't been addressed by now. Do we need a new protocol for communicating with key servers? Is my suggestion above completely crack-addled? If you didn't get the chance to flame me for my previous entry, don't miss your opportunity this time around. ;-) Another possibility would be to change GPG so it doesn't complain about the sorts of problems it found in my message, but that seems suboptimal. Well, okay — I'll say it — grody. Errors in any large collection of data, such as the keyrings in the OpenPGP global web of trust, are inevitable. Corrupt data is corrupt data, should be reported as such, should be susceptible to rectification, and that rectification should be able to be propagated. It seems the PGP key servers — the ones I and many other Debian developers use, anyway — are not entirely succeeding on the last front. What can we Debian geeks, as prominent contributors to the global web of trust, do to resolve the problem? Alexander: I'm sorry I gave offense, if inadvertently and only temporarily. There are certainly no hard feelings on my part. I don't really know how to constructively reply to Matthew, given his patient explanation to me at DebConf 5 that the entire purpose of that specific blog of his is to serve as a vent for his spleen — he has another for the serious stuff. Since it seems to be necessary to state this for the record, I don't regard damaged packets in a person's GPG keyring to be evidence of flaws in the owner's character or personality, or as anything to be ashamed of, but I must admit that I didn't consider that others might do so. I see a technical challenge to be surmounted (noisy spew from the gpg program that seemingly can't be eliminated without improving the way GPG clients and key servers communicate), and that's about it. I welcome people's ideas on resolving it — is there a Public Key Server Corrigendum Protocol in our future, perhaps? *Being relatively new to blogging, it's certainly possible I have in mind a meaning of "discussion" in mind that is excessively mundane, and not the norm. I can easily conceive that people who use their blogs primarily as megaphones to air their grievances (and there are many — one of my favorites is Billmon) are more likely to assume others apply their blogs to the same end. I'll need to give that conception more weight in the future.

Branden Robinson: The Lucky Winner

Last night at the "formal dinner"* at DebConf 5, Anand Kumria presented me with a nice little tote bag that says "Debian: 10 years, 100 countries, 1000 developers, 10000 packages". It's a couple of years out of date now, but still pretty cool. Anand suggested that we give it away as a sort of prize. Since I was sitting across the table from former DPL Wichert Akkerman and we had two other former DPLs in attendance, Bdale Garbee and Ian Jackson, I thought I'd sweeten the item's collectibility by having all of us autograph it. This was swiftly done. After much dithering among my tablemates and I, and many ideas that fizzled regarding closed bugs or frequency of usage of the term "cabal" on the mailing lists, we ultimately settled on a method that was reasonably fair, if boring: the old game of "guess the unsigned 16-bit integer". We went outside and proceeded by binary search, disqualifying half the group at a time. The ultimate winner was Frank Lichtenheld, who guessed that the number was between 20k and 24k. *Fortunately, the dress code was not formal — the formality was that we ate from plates instead of cafeteria trays. ;-).

Dann Frazier: The *real* reason d-i is busted w/ (some?) cciss controllers + ramblings on stable kernel updates

I recently blogged about how fixing d-i on cciss was just a matter of backporting a new version of the driver. Well, I was full of shit. Turns out my test case will give a false positive sometimes - oops. Anyway, the real fix requires backporting two fixes. Hopefully we can get this fix into a sarge point release at some point. On that note, I've started usertagging bugs that I think should go into a sarge kernel point release, should we ever do one (Note: the kernel team/stable release manager haven't discussed what is/is not acceptable in a stable kernel update, so this is just a wishlist at this point.) In my opinion, any localized fix that has already gone upstream and can be easily tested should be permitted. I'd really like to put driver updates in that category, but that opinion maybe tainted by my day job. We maintain a branch of the sarge d-i stack that has a side-goal of adding support for new HP hardware. We keep it as close to sarge as possible (backporting drivers to 2.6.8, for example) with the hope of pushing as much as possible into a sarge point release. Thanks to Andrew Patterson it has pretty recent cciss & fusion drivers. If there is interest, I could probably start posting these somewhere public.

Dann Frazier: New Pornographers, Destroyer & Immaculate Machine

I hadn't heard of Immaculate Machine before, so I downloaded the mp3s they had posted online. They sounded pretty awesome, so I made sure to show up early. Not since the last New Pornographers show have I gotten such good parking at the Gothic (the marquee in the back). Not only that, but some guy with an extra ticket sold it to me for $15 ($17 at the door). The night was starting out right. Just as I walked in and ordered a Gin & Tonic, Immaculate Machines started their set. They were pretty upbeat & rockin; I picked up their new CD. Destroyer played next. I'd listened to a number of tracks available from their site as well. A few of them were pretty good; I really liked the tracks with the horns - but they didn't bring them to the show. I like Dan Bejar's vocals on the New Pornographers albums, but I'm not much of a Destroyer fan. The New Pornographer's set was excellent. They started off with Twin Cinema & Use It - their first two singles off the new album. I always think its cool when bands get their singles out of the way; but that might just be me remembering a Rolling Stone article about the Breeders, and how cool the author thought it was that they started the set with Cannonball. The vocalist/keyboardist (and also Carl Newman's niece, it seems) played the entire set with them, as did the bassist from Destroyer. Dan Bejar came out for a few songs and seemed to be getting a bit a little tipsy near the end. A lot more people showed up than last time I saw the New Pornographers. But that's probably because they were competing with a Flaming Lips/Modest Mouse show the same night.

Filippo Giunchedi: first post, dc6 ends

It appears that I managed to get added to planet. Sadly, my first post starts with an end, namely debconf6 has just ended. I would like to thank everyone, from orga people that made this possible, to everyone who has been able to attend this great event.
This has been my first debconf but I'm sure not the last! don't forget to visit the debconf photo gallery. don't forget also that now you can trash your toilet paper in the toilet (and yes, in madrid airport I was looking around for TEH toilet paper basket)

Benjamin Mako Hill: Upcoming Talk at CEOS

In a few weeks, I'm going to be giving the keynote address at the the Conference on Engaging in Open Source at Dalhousie University in Halifax, Nova Scotia. The conference is organized by the student chapter of the ACM at Dalhousie and looks like a unique, and very interesting, gathering. My talk will build on some of my previous critical analyses of the unique process of principle-setting in the free and open source software communities and will try to introduce some new and challenging concepts while framing the broader discussion that will continue in the rest of the conference. The conference will be held on June 1 & 2, 2006. Ping me if you're in the area and would like to meet up.

Benjamin Mako Hill: The Official Ubuntu Book

Any Day Now, The Official Ubuntu Book will show up in stores. I have a rubber-banded-together copy of the folded and gathered sheets and the the first batch of books should be bound (or being bound) right now. Those who have pre-ordered it from Amazon or elsewhere should have it in their hands quickly. In addition to my own name on the author page is (future Ubuntu Community Manager) Jono Bacon, Corey Burger, Jonathan Jesse, and Ivan Krsti . Many more members of the Ubuntu community and many editors at Prentice Hall deserve credit as well. I'm proud of the book. I sense that it's more consistent, better organized, and of a higher overall quality than my last book. Even better though, is the fact that the book is released under a Creative Commons Attribution-ShareAlike license. Several chapters are already being shipped by default on the Ubuntu desktop and several translations are underway. You can read more about the book on the publishers site and order it from any number of places online. Books under such licenses are economically risky for publishers so please support the project by buying it if you end up finding the text useful!

Benjamin Mako Hill: Taking the "Open" out of "Open Media Commons"

There's a disturbing little press release floating around where the Sun-backed Open Media Commons announces it's release of a new DRM specification to be implemented using free software. That people are creating DRM systems under open source and free software licenses is not surprising; much of the encryption technology on which DRM is based has been free and open for a long time. What is disturbing is that it contains what appears to be an endorsement by Lawrence Lessig:
Lawrence Lessig, Chairman of the Board of Directors of Creative Commons and Professor of Law at Stanford Law School: "In a world where DRM has become ubiquitous, we need to ensure that the ecology for creativity is bolstered, not stifled, by technology. We applaud Sun's efforts to rally the community around the development of open-source, royalty-free DRM standards that support "fair use" and that don't block the development of Creative Commons ideals."
Lessig's position seems to be that DRM is bad and should not exist. But in a world where it does exist, he thinks that not-quite-so-bad DRM is better than the alternatives. Is that the sort of message we want to be sending? The fact that the software is "open source" is hardly good enough if the purpose of the software is to take away users freedom -- in precisely the way that DRM does. It doesn't help that EFF has already spoken out against this project. Lessig is on the board of directors of both EFF and FSF. I think it is smart for members of either organization who are opposed to DRM, even when it's sweetened up, to contact those organizations and let them know how you feel. On the OMC website, there is a photo of two young attractive people listening to a single pair of headphones. Apparently, the people in the picture need to share a single pair of headphones because the Open Media Commons rights management system won't allow them to share the digital media itself.
/copyrighteous/images/omc_sharing.png

Benjamin Mako Hill: System.hack()

My friends Marcell and Tomislav organized a show called System.hack() that aimed to highlight many of the last half-centuries greatest "hacks" as a means of celebrating the hacks themselves while exposing them, and the idea of hacking and hackers, to a larger audience. As part of their show, I procured an original circa-1960's Cap'n Crunch whistle (the one that emits 2600 Hz when one hole is covered) and wrote a short essay for a book published along with the show. You'll have to track down Tomi and Marcell in Zagreb if you want to find my whistle but you can read about the hack in either English or Croatian on the exhibit's wiki. You should also check out the whole System.hack() wiki because there's some other good stuff up there from other contributors.

Isaac Jones: Announcing Haskell'

let haskell' = succ haskell98 in
Announcing the Haskell' ("Haskell-Prime") process.  A short time ago,
I asked for volunteers to help with the next Haskell standard.  A
brave group has spoken up, and we've organized ourselves into a
committee in order to coordinate the community's work.  It will be the
committee's task to bring together the very best ideas and work of the
broader community in an "open-source" way, and to fill in any gaps in
order to make Haskell' as coherent and elegant as Haskell 98.
Our task is broadly defined by our mission statement:
    The Haskell programming language is more-or-less divided into two
    "branches".  The Haskell 98 standard is the "stable" branch of the
    language, and that has been a big success.  A lot of progress has been
    made over the last few years in the "research" branch of the Haskell
    language.  It is constantly advancing, and we feel that it is time for
    a new standard which reflects those advancements.
    Haskell' will be a conservative refinement of Haskell 98. It will
    be the work of this committee to adopt a set of language
    extensions and modifications and to standardize a new set of
    libraries.
    We will strive to only include tried-and-true language features,
    and to define them at least as rigorously as Haskell 98 was
    defined. This standard will reflect the realities of developing
    practical applications in the Haskell language. We will work closely
    with the rest of the Haskell community to create this standard.
Your Haskell' Committee is as follows (slightly munged email addresses
follow):
 * Manuel M T Chakravarty <chak at cse.unsw.edu.au>
 * John Goerzen <jgoerzen at complete.org>
 * Bastiaan Heeren <bastiaan at cs.uu.nl>
 * Isaac Jones <ijones at galois.com>
 * John Launchbury <john at galois.com>
 * Andres Loeh <loeh at iai.uni-bonn.de>
 * Simon Marlow <simonmar at microsoft.com>
 * John Meacham <john at repetae.net>
 * Ravi Nanavati <ravi at bluespec.com>
 * Henrik Nilsson <nhn at cs.nott.ac.uk>
 * Ross Paterson <ross at soi.city.ac.uk>
 * Simon Peyton-Jones <simonpj at microsoft.com>
 * Don Stewart <dons at cse.unsw.edu.au>
 * Audrey Tang <autrijus at gmail.com>
 * Simon J. Thompson <S.J.Thompson at kent.ac.uk>
 * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk>
 * Stephanie Weirich <sweirich at cis.upenn.edu>
The editors are Isaac Jones and John Launchbury.
Feel free to contact any of us with any concerns or questions.  If you
don't know who to direct your questions to, email Isaac Jones
ijones at syntaxpolice.org.
Community involvement is vital to our task, and there will be a way
for members of the community to make formal proposals.  In the opening
phases, please use these more informal resources to help us coordinate
Haskell':
 * The haskell-prime mailing list.  All technical discussion will take
   place here, or (if other meetings take place) be reported here.  Anyone
   can subscribe, and any subscriber can post questions and comments,
   and participate in discussions.  Anyone can read the list archives.
   http://haskell.org/mailman/listinfo/haskell-prime
 * A wiki / issue tracking system to document consensus and to track
   ongoing tasks.  This system is publicly readable, but only
   committee writable so that we may present it as the "official"
   output of the committee.  If you ever feel that the wiki is not
   accurate as to the consensus, please alert the committee!
   http://hackage.haskell.org/trac/haskell-prime
 * A darcs code repository for experiments, proposed libraries,and
   complex examples.  darcs is a decentralized system, so anyone can use
   it, but patches should be sent to Isaac Jones:
   http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode
Please join us in making Haskell' a success.

Isaac Jones: How to get involved in Free Software (the bug method)

Are you a software developer? Are you graduating soon? Maybe you should get involved in free software projects! There are any number of reasons people get involved, from altruistic reasons to selfish reasons. Let's approach it from a "selfish" point of view. I assert that involvement in free software projects looks really good on a resume, and is an excellent way to "network". Networking isn't all about schmoozing at job fairs; it's about building a reputation with professionals in your field. There are very few fields where a huge number of professionals are so very accessible. Software developers are very lucky in this sense. Common wisdom seems to indicate that the job market for software developers is very competitive, and it's going to continue to be competitive for a while yet. Any edge you can get over your classmates is going to help. There is plenty of opportunity to contribute, no matter what your skill level. There is documentation to write and there are translations to perform. There are bugs to fix, and packages to create. Of course there are projects that need more "serious" development as well. You don't have to start your own open-source project, and you don't have to learn to hack on the Linux kernel to add something very attractive to your resume. When people ask me how to get involved in free software, I usually recommend that they start out reporting bugs in the open-source software they use frequently. You might install a version of GNU/Linux, or if you want to stick with Windows or MacOS, you should browse around to find out what free software is available. I think you'll be pleasantly surprised. Let's use "Gaim", a multi-protocol IM client, as an example of how this might proceed. Gaim runs on Windows, GNU/Linux variants, and I'd expect MacOS X, and Unix. It's open source and free: http://gaim.sourceforge.net/. Download Gaim and the Gaim source code. Build it for your machine if you want. Notice what language it's written in. Do you know this language? If not, can you understand it (if you know Java, you can probably understand a lot of C, for instance). Try out Gaim, set up your AOL Instant Messenger and your IRC channels. Visit some open source channels. See any problems? Check the bug reports to see if anyone else has seen that problem. If not, report it as a bug (you might want to google for "how to report a bug" first). Now check out the "bug reports" for Gaim. Pick a bug and try to reproduce it. Why are bug reports the first step in improving your resume?
  • Reporting a bug is a half-hour task.
  • Fixing a bug is often (not always) a small, weekend-sized task.
  • Bugs introduce you to the source code on a level where you don't have to understand everything (hopefully).
  • You will build familiarity with debugging tools which are invaluable for a developer.
  • You will start to build a reputation with the authors of the software, and in the free software community.
  • And because developers are always very happy to get bug fixes that they didn't have to work on themselves. Let's take a look at the bug list for Gaim again. Different ways to contribute to fixing a bug:
  • If you can reproduce the bug, you might add more information to the bug report: What steps did take to reproduce it? Is there a unique combination of features you need to be using to cause the bug?
  • If you can't reproduce the bug, maybe it's fixed in the version you're using! Maybe you should add that to the report (better read and understand it very carefully first). Pick another bug, repeat.
  • Depending on your skill level, you might try to fix this bug, or at least isolate where the bug came from. If you manage to fix it, read about the "diff" and "patch" utilities. Send the author a patch, or attach the patch to the bug report. Here is a bug that looks pretty easy, and it doesn't look like the developer is particularly thrilled to spend time on it: "Buddy Pounce does not get removed when user is deleted". I'm going to take a wild stab at how you might fix this bug: most probably, there's a "list" of "pounces" that has a data-structure which contains both the buddy's name, and the pounce action, whatever that is. Find the code where the buddy is deleted from the buddy list (a different list). Add code to search through the "pounces" list to delete that buddy from the pounces list as well. Compile, test, and run diff to create a patch, attach it to the bug report, take a bow. Now add this to your resume. You are now 50% more interesting to me, as someone who reads resumes, than your classmates who have never taken on a project outside of school. You've shown initiative, skill, and maybe even teamwork. Higher levels of commitment If there's a piece of software that you love, that you think is really important, then you might try adding features to that software and joining the development effort. Lots of projects have a page dedicated to information about how to help out. Here is one for the Mozilla project, for instance. If you want to lead a development project, you might adopt one that has been orphaned. Many people recommend against starting your own project off the bat. I've presented you with a method to increase your skill and reputation, and to add something interesting to your resume. Try it out. You might find out why so many software professionals work on free software projects. It's tons of fun! Feel free to send me comments on this document, or to tell me whether this advice has effected you.

    • 3 September 2006

    David Nusinow: So Much For One Entry A Day

    Too many good responses not to reply now. Both aba and buxy suggest merging the steering committee with the DPL, thus allowing such a committee to be elected democratically. This has its merits, but I'm hesitant for one main reason: Project SCUD was a complete and utter failure from the point of view of many DD's, myself included. There were reasons for it, and I'm sure they're valid, and I'm not blaming anyone, but it does make me distrust that structure for anything useful. The DPL as an office has had the opportunity to create this sort of structure and make it work for a long time now, and it hasn't happened. I'd imagine it's because the DPL is simply bogged down with other things. If the DPL could make this happen, I'd be fine with it, but our past experience suggests that we need a different solution than a non-functional DPL team.

    The current setup, with the 2IC, seems to be working very well, but it's not actively going after issues in this way, even though it has the authority to do so. Indeed, I think if the DPL did start exercising his authority in this way, people would complain and threaten to resign and so forth. While many of us might envy Ubuntu's success, I don't think we really want the DPL to become a dictator.

    The tech-ctte, on the other hand, works very well when things are brought before it, even moreso now that it's been revitalized. Allowing the DPL to delegate the steering committee would allow fresh faces to replace inactive ones each year, which would be a further check on the committee's powers (which I've done my best to limit to the scope of the problem). Also, by acting as a delegate of the DPL, the committee is essentially a focused extension of whatever team the DPL has assembled. By having a group of people who are focused on this specific task, it allows them to get work done without being bogged down by most of the issues that the DPL faces. I admit that this takes some of the glamor out of being DPL, but there's nothing wrong with having the DPL as a member of the steering committee that I can see, provided the committee is large enough. One possibility I've considered is to make the DPL the chair of the steering committee by default, which would give them the same powers as that of the tech-ctte chair.

    As for how the steering committee would work with the release managers, it would, as madduck said, be a fairly close relationship, with some very likely overlap. The RM's are currently loaded up with plenty of work just making the current set of packages and features tight enough to release. Adding the burden of crafting and helping implement a vision isn't something I'd want to force on them. The RM's should be, as they currently are, concerned primarily with getting a high quality release out the door. They would remain the focal point for transitions and RC bug fixes, as well as determining what is actually release critical. The steering committee would give people the power to work towards release goals (hence working closely with the release team) but they don't have the power to say that the release should be held up for any given feature. That power would belong to the release team, the same way it currently does. I'd imagine that any release goals set by the release team would be approved by the steering committee without much effort.

    One final issue. The tech-ctte works out in the open, on public mailing lists and the BTS. Team SCUD, as well as the DPL in general, does not really work out in the open. While I think having some things taken behind closed doors is good, I feel very strongly that the steering committee would have to do its work out in the open in the same manner as the tech-ctte. This is a major reason why I don't want the DPL office to take on this power.

    Rapha&#235;l Hertzog: Steering committee or board?

    There’s a new idea floating around: creating a steering committee for Debian. I like the principle but I think we should aim for a broader change in the constitution. I don’t think creating a new separate structure is a good idea, because in my opinion the DPL should be the steering committee. Of course a single individual can’t play that role. And in fact, this is true for almost any task that the DPL currently has to handle. So we need to get rid of the DPL and to replace it with a board. And that board would be the steering committee and would also have the responsibilities that come currently with the DPL hat. Why? First of all, the role of DPL is to provide a vision but most recent leaders have not been able to do that as they tend to get overwhelmed by simple administrative work. If you remove the hope to effectively lead Debian by giving that power to a committee, then you scare everybody that wanted to be DPL because it effectively become an administrative position with no interest. Then, in recent years, the DPL position tended to become a multi-person thingie, first with the DPL team idea and this year with the 2IC (sort of a “DPL assistant”). So it looks like we’re ready to switch to a fully multi-personal leadership: one of an elected board. And last point, since the DPL tends to be active only on internal organizational issues, for most persons he’s only working on “political” stuff and he’s not valued as contributor leading the distribution where it needs to be lead: to the next release. That’s why I suggest that the board should be elected for an entire release with a maximum of 21 months. After each release we elect a new board and it should be in place for 18 months ideally. Tying the term to a release seems like the right approach to me: at the beginning the board is effectively doing most of its work as steering committee (setting/approving release goals) and at the end, during the period where we’re freezing it has more time to concentrate on organizational issues. The questions is now: how is that going to work with the release managers? Will that position become only an administrative work of low-level coordination without any influence on the whole distribution?

    Clint Adams: Your argument is invalid if it is not filled out in triplicate

    Lars, I realize that some people consider argumentation with references and citations to be more sophisticated and valid than messages with actual content, but it is, more often than not, irritating, lame, and disingenious. This reference proves the point.

    Martin F. Krafft: Never give up

    Scott, the first thing I want to say in response to your post is that you are not alone. I did not know someone was attacked for wearing an Ubuntu shirt in Helsinki, but I did witness at least one "Fuck Ubuntu" incident, and it seemed that Ubuntu jokes and snaps at the new distro were very common. I find this utterly childish and stupid. I am sorry for everyone who was offended. But please don't blame or condemn everyone in Debian or the whole project for the actions of some of its members or followers. You've already linked to my thoughts on the Ubuntu-Debian situation, so I need not cover any of that anymore. I wouldn't want to either, because believe it or not, this article got me flamed by Ubuntu developers just way too many times, in personal mails as well as in forums. Instead, let's look at the now and then this time. I've heard a few developers express their unhappiness with Debian in the past year, much in the same way that you did. Not always was it related to Ubuntu, but quite often it was. There are newcomers to Debian who shake their head in disbelief how anyone can work in a project such as Debian, and there are the veterans among us who seem to concede that Debian has slipped away from their ideals and it's just not fun anymore. It's not hard for me to understand each of them. I've followed Debian for nearly a decade now and thus tracked how it changed over time. We are one of the largest free software projects, and size never comes without problems. So while the Debian project used to be an association of geeks enjoying their focus on technical excellence, the sheer growth of our project called for many other fields to be managed, and we did not always handle this increase in complexity very gracefully. After all, we are all just geeks who want to have fun, aren't we? As a result, several aspects of our project have been said to "stagnate", and parts (and parties) have diverged. As a volunteer developer, it's not always fun to run up against walls and find that your innovativeness is met with stubborness or simple silence. I say "not always" because I think it's really just a matter of perspective. Over the years, Debian has seriously affected my life, the way I look at things, the way I interact with people, and the way I do stuff. I am eternally grateful for much of that. But the learning process has not stopped. What Debian needs is a stronger grasp of the big picture. In joining all the other developers who are already doing excellent work in that direction, what better learning opportunity could there be to approach large-scale project management, away from academia and the corporate world. For me, this is a very interesting perspective of a fascinating project, one that directly relates to my current research endeavour. I was asked recently how we "control the anarchy", and the first thing I said was that "control" was not the right word. Debian is not about control, it's about the flow. If it's not going your way, you can swim against it, you can pull out, or you can try to find ways to change that flow, bottom-up rather than top-down. I think David's idea of a steering committee is an excellent one, and I'd be happy to dedicate time to such an effort. I wouldn't call it "steering" though, as that seems too active. Rather, I envision a group of people dedicated to keeping track of the big picture (obviously in close contact with the release team) to which developers can turn if they need advice. In the last few years, I've often asked myself why the heck I don't just give up, instead of continuously running up against problems that seemed hopeless. Even now, I sometimes think that I should have just pulled the plug, but my answer has always been no, and it looks like it'll remain that way. Why? Because we've come an incredibly long way, and that by itself provide for a lot of motivation. Mostly, however, I decided to hang in there because I tend to like challenges, even if at first I have no idea how to conquer them. When I then look at what some of the people are doing for the project, I come to realise that there are solutions, even if the road is a long one. You (Scott) strike me as a very innovative person, and not only because the problems you and I are looking at tend to overlap to a large degree. I strongly respect you for your work, and Canonical certainly deserves a tip of the hat for providing you with the environment to do so. Sometimes, I even envy you a little, simply because I haven't been able to get down to coding solutions as much as I would have liked to and you've beaten me to the punch on things like HCT or upstart -- even though my work in that area has been mostly vapourware, so there was no real punch to which you've beaten me... I think you'll know what I mean. Yet, scanning some of your older blog posts, I got the impression that you weren't always happy with the way you have to do things at Canonical. And still, you're enthusiasm for working on your projects is astounding; it wasn't hard to come to that conclusion just a week ago, even though we've only talked briefly in Cambridge. Have you asked yourself why that is? I'll go out on a limb and postulate it's because of your innovativeness, because of your urge to push technology further, to implement cool things, and to break free of the cruft that comes with 13 years of Debian and several decades of standards la POSIX and SysV. Debian is too conservative for you, and all the cruft weighs heavy. Ubuntu, on the other handy, is "fluffy" and not afraid to forge ahead, and you've been an active part of it from day one. As much as I hate to see you "with them" rather than with us, I think you've found your place. And so have I. I'm less about coding than I am about integration, and there's work to do. Debian is a massive project with an amazing track record of achievements to look at. And it has problems. Well, great! Let's attack them. Never give up. Another reason why I've stayed with Debian is because there are people who think alike. Three years ago, I would have been able to give you a long bullet lists of hopeless problems in Debian. If you ask me today, I would have problems arguing their hopelessness, for I've seen plenty of developers taking it up with these problems, and in the meritocratic way. Our release team is doing a fantastic job and I've never felt so positive about the promise we made with the next release. People like J rg, Zobel, Rapha l, the two Alex, Meike, Christoph, and the many others I'll leave out only in the interest of brevity (the list is longer and doesn't only span Germany and France) are doing great work, and that is truly motivating. And I ought to mention explicitly our leader, Anthony, who's been doing an excellent job so far. I hope he can keep it up. Also, take a look at our IRC channels. I would have to be lying if I'd say nothing has changed. And the same applies to mailing lists. We still have a reputation to deal with, but if you stop listening to what people say and actually take a look, I think we've come a long way. I'd even say it's become more fun to work on Debian again! I think we owe a lot of that to Debian Women. I am definitely proud to be a member of this community (with which I mean Debian as a whole, not just Debian Women). I think I could continue this blog post endlessly. Let's not. You (Scott) may not be a fellow DD any longer, but you remain a fellow D, and I hope we'll continue to let our cooperation prosper. Now if only you had told me that "getting upstart installable required changes to twelve different packages, including sysvinit itself" when you approached me with what sounded like a simple sponsorship request... I've started to have a go at the "herculian effort", step by step. Seems like an interesting experiment. NP: Eels / Daisies of the Galaxy (it's really hard to find a better band for a grey Sunday morning) Update: Maybe our reputation isn't all that bad, or Slashdot posts suddenly became all useful. A lot of insightful and interesting posts in the first batch of comments...

    Evan Prodromou: 17 Fructidor CCXIV

    Hard to believe it's been more than a week since I posted on my blog. It's been a fun-filled week; Maj, Amita June and I took a cruise of the Baltic Sea. It was everyone's first cruise, as well as our first time in the area, so we did a lot of travelling -- hitting wt:Lubeck, wt:Visby, wt:Stockholm, wt:Tallinn and wt:Saint Petersburg during the week. Unfortunately, our onboard Internet connection was neither easy to use, reliable, nor cheap, and our time on land was too short (about 8-10 hours per city) to waste in Internet caf s. I did manage to get wireless in Tallinn, which famously has free municipal WiFi, but otherwise I was stuck with exorbitant satellite-feed access on board our ship. Most of my time online was making sure that Wikitravel wasn't crashed while we were at sea. (It's my constant fear -- as soon as I get out of range of easy Internet access, I'm sure that either the servers have gone kaput or there's an exploitable bug in the software. Either way, I'm pretty nervous on most trips. Kind of ironic, in a way.) Suffice it to say that it was really a worthwhile, good time for us. We're back in wt:Copenhagen today. I'm trying to catch up with a couple of Debian developers and NM candidates to exchange wp:OpenPGP key signatures, and trying to plan our scant 23 hours in wt:Zurich starting tomorrow. tags:

    Blogue My friend Nicolas Ritoux, an Internet and games journalist in wt:Montreal, has a new blog at http://www.vulusu.ca/ . Vu, lu, su means "seen, read, known" in French, and I think it makes a lot of sense for the name of his blogue. He's got a near-comprehensive view of Internet and video gaming culture, and I think that this blog will be a nice addition to his weekly columns in La Presse. tags:

    2 September 2006

    Aigars Mahinovs: Eternal unstable?

    More and more early adopters choose to use Ubuntu instead of Debian. Ubuntu has newer versions of the software that matters (XOrg, FF, OOO, Gnome,…) than the stable Debian or, sometimes than even the unstable Debian. Early adopters are the users that are most eager to try new shiny things, do not scream too much if those things break and seem to make good bug reporters. They are the key second level - just below the developers and above most users in the pyramid of software development and use. They are also the people that have a tendency to become developers. That is why I have this feeling that capturing early adopters is essential to development of a thriving free software community. How can that be done? I do not know, but I have an idea that might just work. What I envision is a merger of development processes of Debian, Ubuntu, Knoppix, Skolelinux and all other Debian derrived distributions. The base for this merger would be an eternal unstable line where all developers would be encouraged to put the newest and greatest software - THE place to be if you want to be on the bleeding edge. I see this unstable line being much newer then Debian unstable, but retaining similar level of quality (how? it is a good question). Then there would be a set of tools available to splice packages from this unstable line into a stabilisation and stable branches for each distribution. The tools would be the same for all distributions and the packages would be the same for all distributions, the difference between distributions would be achieved by the way that the packages and their specific versions are chosen, patches applied for a particular distribution and in some ways by the assembly of the final release media. The proper Debian releases in this context would be no different then Ubuntu releases but will be created using different criteria and at different times. The tools must be powerful enough so that release preparations of any distribution (including Debian proper) would not need to slow down the progress of the flow of new features into the eternal unstable line. The infrastructure needed to operate such complex system would be immense. It would need to have some similarities to the systems Debian uses for distribution, release and bug management, it would need to have some similarities to Ubuntu’s Launchpad (just free, understandable, usable and well documented), and I think that it would also need to have some similarities to Gentoo’s Portage system (distros do want to recompile packages with different options and with their own library versions). It would also help if this unstable line could still hold few parallel versions of one package - like the latest release and the cvs version. (However I am pressed to even imagine all the complexities this would bring into apt and bug reporting/debugging.) I think that such structure will not only concentrate the scarce resource that are the early adopters in a place that will benefit all distributions, but will also provide extra dimensionality for social and technical growth for The Debian Project. The Debian Project will turn from a single great distribution to a swarm of wonderful distributions with a strong central spine - the eternal unstable line. An additional benefit to this will be that it will be possible to fork Debian if social pressures require that (like it happened with gcc vs. eggc) for the benefit of all free software users. Like, for example, the David’s steering commitee whould not disturb the Debian main line until it has been proven to work - it could be formed, it could set goals for a branch and feel in total control of their release goals and methods. After the steering commitee makes a successful release, it would be only a matter of a political decision of whether to call that release Debian proper or not. Note: As always this is just an uniformed rant of a relatively passive DD who is blissfully ignorant of pretty much everything, so please tell me if and why it can or can not be done. P.S. While I am in such writelly mood, I should probably write that free software advocacy article for a new journal that I promised them a month ago. P.P.S. If the system is written with it in mind, then each user’s computer could theoretically be a separate distribution which keeps a splice of Debian unstable line (or any subline) with local modifications and possible local compilation options. If done right, this could also provide a ground for merging up with Gentoo. P.P.P.S. After reading trough logs of several bugs on the Launchpad, I have a feeling that Ubuntu is being flooded by much more bugreports then Cannonical is designed to handle (especially for free). I am not pointing fingers here, I am just suggesting that it is another facet of the same problem and that this idea of mine could reduce this load and let Ubuntu developers concentrate on what they really want to do.

    Aigars Mahinovs: Wrong partition ordering

    If you have a hard drive with two or more logical partitions in one extended partition and then proceed to erase the first of those logical partitions (in GParted), then you will soon discover that the number of the second logical partition changed (from sda6 to sda5 in my case). If you then try to create a partition in the free space and launch cfdisk, you will notice that there is no free space where it should have been. If you then manage to get to GParted and create a partition there, then do not relax, as your perils are not yet over. Upon reboot you will find that the logical partition that is in the beginning of the logical partition got a new number (sda7 in my case) and the your valuable second logical partition is still numbered wrongly (it was sda5 instead of expected sda6). Even more so, if you try to fix it with cfdisk, it bails out with a fatal error of overlapping extended partitions. The fix is to start fstab, press “x” for advanced operations and press “f” to reorder the partitions according to the order on disk (do not forget to enter “w” to write the changes). That fixed the problem. But I have no idea who to bug for this wonderful Mongolian Clusterf*ck of Partition Numbering. And that is only a tiny preview of the immense fun I am having right now by trying out installations of Debian etch and Ubuntu edgy on my Dell M1710. If you want a stable desktop on this computer right now - use Ubuntu Dapper (with nvidia binary drivers). You will have much unneeded fun with IPW3945 wifi and the NVidia video card drivers otherwise.

    Next.

    Previous.