Search Results: "xam"

4 September 2006

Branden Robinson: On Leader Reports

Philipp Kern : to put it simply, you're right. I appreciate your frankness, and yours is exactly the kind of feedback I need to do a better job. The primary reason for transitioning DPL reportage from monthly reports to blog entries is because I have found that most things in Debian that require my attention do not unfold neatly on a month-to-month basis. The ongoing attention to stable security updates, for example, began in June, carried forward through DebConf, and brings me to Oldenburg this weekend. Activity tends to be "bursty" instead of steady, which makes sense given that most of us don't have salaried jobs we can dedicate to Debian (I don't, certainly — my day job just has some overlap with my avocation). The emphasis I placed on visibility, demystification of Debian processes, and reform of the ones that don't work well remain my focus. To that end, it seems logical to me that it would only compound a failure to issue monthly reports by withholding information until I do issue one again. I'm trying to keep people informed, and if the information I've been sharing via my blog entries about DPL matters is of little value, then I need to know that — please tell me. planet.debian.org, by virtue of its .debian.org address, is an official project resource, which is why I think it's a suitable forum to use for communication with Debian's developers and users. Similarly, I am acting in my elected position when I post to any other Debian mailing list, even though subscription to other lists by developers is not required, and I act in that position when I speak with the press. I expect to be held to account for my statements in those forums, and I suspect you'd agree that I couldn't avoid responsibility for them by claiming that I didn't make them to debian-devel-announce. Whether I have good reasons for falling behind on the monthly reports or not, and whether or not I still think now they are the best way to maintain visibility is beside the point. I fully expect, if I run for election against next year, for my rivals to make much of the failure. My primary concern, however, remains serving the membership of our organization, and the users of our distribution, as best I can. To that end, I have a question for you and others: should I re-post blog entries about leadership matters to debian-devel-announce, or is that needlessly duplicative? Along the same lines, is it desirable that I stop (or reduce) blogging in favor of emails to debian-devel-announce? Let me know what you think; post to the Planet, and/or mail me at leader@debian.org.

Branden Robinson: Destination: Oldenburg, Mission: Security, Java, and a bit of odd old hardware

On Friday afternoon I'll be arriving in Oldenburg, Germany, for the eleventh annual Linux developers' conference. Historically, this conference has had a strong focus on non-x86 ports of the Linux kernel, boot loader development, the GNU toolchain, and so forth. At long last, it looks like this may be my opportunity to get my Macintosh Quadra 840AV out of mothballs and back into commission, thanks to Wouter Verhelst. I should be able to fit it into my luggage if I don't bring many clothes... :-) This year, however, in addition to that, a couple of mini-conferences are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian Java DevJam and the Debian Security Summit. The Java programming language is a divisive issue in the Free Software community, and has a degree of controversy that sets it apart from the usual language wars. The dominant factor in this controversy stems from what Richard Stallman refers to as the Java trap; with the specifications controlled, and the reference implementation kept unavailable on DFSG-free terms by, an industry consortium dominated by large corporations, a Free Software hacker might fear that using Java will consign them to either having to compromise their principles by using non-free class libraries (for example), or being doomed to chase the taillights of standards that could conceivably be tailored to disadvantage competitors. (Java is not alone in this respect; many people fear that Microsoft's .NET, despite being openly standardized through ISO/IEC, will in actuality be completely controlled by Microsoft.) Despite this peril, Java is attractive to GNU/Linux-using organizations. The Free Standards Group, developers of the Linux Standard Base, has received inquiries about a Free Java standard and implementation from organizations already committed to GNU/Linux. In my job, I've encountered an interest in Java from several customers and prospects. Intriguingly, these institutions are, by and large, very much aware of the Java Trap. They like the language, and are not strong advocates of Free Software, but they too are worried about vendor lock-in. They've seen the success of community-driven development as GNU/Linux moves from strength to strength, claiming territory formerly held by Microsoft and proprietary versions of Unix. Even if I can't persuade a customer to adopt a Free Java stack, I can exhort them to only code against Java standards that have seen a free implementation. That way, their development bets are hedged against any "madman theory" of the controlling vendor. Furthermore, this way they only code to standards that are seeing independent implementations, and they leave their engineers free to switch between varieties of development kit. Engineers like flexibility because it enables them to work more efficiently; sales people, marketing personnel, and strategists like efficient engineers because they make a firm more nimble. That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want to see their implementations fully mature, and are working hard to make it so. The Free Software community has the opportunity to make its Java implementation not just an available alternative, but a compelling alternative to the proprietary ones on technical as well as licensing grounds. The recent release of GNU Classpath 0.18 shows just how vigorously this opportunity is being seized. Having mature software is only half the battle, however; that software has to be coherently put together and easy for the user and developer to manipulate. For many of these folks, it's not enough just to have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers and interpreters (gcj and gij, respectively, from the GNU Compiler Collection), and application servers (Jakarta Tomcat, JBoss, and JOnAS, among others). They also want these technologies to be mutually integrated and easy to install and use. Good software and good packaging complement each other to drive adoption of the technology, and that's what the DevJam is all about. I'm glad to see that representatives of Debian's Java packaging team will be joining not just upstream authors, but their counterparts at Fedora, Ubuntu, and Gentoo in furtherance of this goal. I've approved a budget of EUR 2000, which Petter Reinholdtsen will administrate, to support the expenses of Debian's participation in the DevJam. We've received 1500 USD in sponsorship of this event from a corporate sponsor that chooses to remain anonymous. The other mini-conference I'll be attending is the Debian Security Summit. We're bringing together the heads of our Stable Security and Testing Security teams — the two Joeys, Joey Schulze and Joey Hess, as well as a bevy of other security-minded people, with the goal of revitalizing and streamlining our security processes. Several members of the Stable Security Team have gone dormant over the past several months (or longer), leaving an increasingly small number people to handle, as of Sarge's release, not one but two stable releases. This is because we do not terminate security support for our previous stable release (in this case, Woody), until some time has passed. We've had other challenges on the security front. We had what amounted to a security support hiatus for about three weeks in June, which caused much consternation. More recently, klecker.debian.org, which provides the security.debian.org has suffered some occasional availability problems, and it hasn't always been clear what's caused them. It's my understanding that we have new hardware in place that can serve in a backup, supplemental, or failover capacity. The general feeling at DebConf 5 was that our security apparatus was in need of attention to make sure it keep pace with the demands being placed on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and others over the past several weeks, and I look forward to a productive few days.

Dann Frazier: git bisect

I've not had much experience with git, but one feature I'm really liking is git-bisect. I often run into cases where a bug exists in one kernel but was fixed in another, and I need to pin the difference down to a single changeset. As an example, I recently discovered that an issue I'm working on in 2.6.8 no longer exists in 2.6.12. So, I went through the manual bisect to narrow the fix down to a changeset between 2.6.10-rc3 & 2.6.10. But that could be any of hundreds of changesets :( I decided it was a good opportunity to try git-bisect. It adjusts my tree to some intermediate state, I build and test. I tell git whether the results of my test were "good" or "bad", and it adjusts my tree once again. Very cool. The only annoying thing about this example is that I had to reverse the meanings of good & bad, because git bisect assumes that you're looking for the patch that fixes a build, not the one that broke it.

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.

Benjamin Mako Hill: The Patent is Pending

We often hear about the technical advances that occur at Debconfs. For example, using only Debconf signage, I once invented a portable toilet that was the size of a single sheet of A4 paper. The picture is a bit blurred but you can get the idea:

/copyrighteous/images/portable_toilet-small.png

Benjamin Mako Hill: Reference Librarian

Mika and I applied for membership at the Boston Athen um today. In addition to paying the USD $160 yearly fee, were each asked to provide three references who can attest to care for books. That's right; three references to get a library card. This is a very good library. We'll hopefully hear back about our application within two weeks. If we are accepted, we'll be able to take guests into the library with us. The Athen um has, among other things, a copy of Narrative of the life of James Allen, alias George Walton, alias Jonas Pierce, alias James H. York, alias Burley Grove, the highwayman. Being his death-bed confession, to the warden of the Massachusetts state prison. It is bound in the authors skin. Apparently, while rare, this is not entirely uncommon. The Harvard Law Library has another example of anthropodermic bibliopegy and just a couple months ago, someone found a book bound in human skin in the middle of the street in Leeds.

Benjamin Mako Hill: I'm Sick

Namie Amuro is a very famous Japanese pop star. Mika pointed me to her most recent album. The title is, Can't Eat, Can't Sleep, I'm Sick.

I like the title! While Namie goes into some detail on the nature of her malady in the title of her piece, I think it would be even better if she did so more. Like, for example, in my new upcoming single, Can't Think Straight, Can't Stop Vomiting, I'm Sick.

Benjamin Mako Hill: Stepping Down From Software in the Public Interest, Inc.

Three years ago, I was elected to the board of directors of Software in the Public Interest, Inc. About halfway through my three year term, I was elected by the board to the (largely ceremonial?) role of Vice President of the organization. This month, my term is up and after a good deal of soul searching over the last weeks, I've decided to not run again. With time, I've become busy with other projects including work and graduate school at the MIT Media Lab, Debian, Ubuntu, One Laptop per Child, several book projects and more. Recently, I've found that I've simply had less time to put toward SPI than I have had in the past. Of course, I continue to care very much about SPI and its mission and feel that I done a good job of fulfilling my responsibilities throughout my term. The real reason I'd like to step aside to let some new blood and energy take a more active role and to let SPI take off in new directions. Since I've served a full term, I thought I would take the opportunity to look back at my work with SPI over the last three years and to the future. SPI's Recent Past Three years ago, I ran for the SPI board on a platform that I would like to see SPI work more like a real pro-active non-profit organization and less like Debian's legal shell. SPI was at at transition point then and the board spent a lot of time thinking about it was that SPI should do and what role it should fill in the free software community. Many of these questions are still open but the following is my round up. There are two types of non-profit organizations in the free/open source community. The first is the large-project foundation. Example are the GNOME Foundation, KDE Foundation, and Plone Foundation. These support and work closely with one large and otherwise institutionally independent project. The second type is concerned with advocacy or issues of concern to many or all free software projects. The FSG/LSB, Open Source Initiative, Software Freedom International, Linux International, and the Free Software Foundation are all examples of this type (although the FSF also supports the GNU Project so can be put into both camps). Three years ago, SPI was basically the Debian Foundation under a different name. However, SPI also supported a handful of other medium-sized projects (at the time, this included Berlin and OFTC). In this way, SPI provided some of the benefits of a 501(c)(3) non-profit organization to groups that were large and important enough to care about issues like the tax-deductability of donations, but small enough that starting their own foundation didn't quite make sense. This, I am convinced, is SPI's niche and its where the organization can make the greatest difference. While Debian continues to be the driving force behind SPI, this mirrors Debian close relationship with other free software projects as a downstream and a distribution. Debian may ultimately decide its has outgrown SPI and wants its own foundation but it's role in providing an umbrella for other free software project also makes a lot of sense. Over the last years, SPI has added several new member projects including GNUStep, Drupal and PostgreSQL and members of these projects have played an increasingly important role in SPI. OFTC members including SPI secretary David Graham have continued to drive the organization. I am thrilled to see that PostgreSQL's Josh Berkus is running for a seat on the board and wish him the best of luck. He has put a huge amount of effort into SPI in the past several months and I believe he would make a great board member. Of course, not everything has been rosy. While our organization is in slightly better shape than it has been in the past, SPI still suffers from a lack of interest and activity by participants in its member projects. SPI handles Debian's money and every Debian developer should be interested and involved in SPI; yet only a relatively small percentage are. I've run SPI sessions, talks, and BOFs at three of the last four Debian conferences but haven't been able to make a satisfactory dent in either the Debian community or SPI. The next board of directors will need to work actively and creatively to help do what the last board did not accomplish. While things are currently much better than they have been in the past, SPI has continued to be mired in a number of bureaucratic issues. Simple issues like accurate, timely and transparent bookkeeping have proved more difficult than the board or those brave (or foolhardy) enough to take on the treasurer position seem to have thought. I worked with the treasurer and our lawyer to meet with a bookkeeping service in New York City. The Future In the future, I'd like see to more members projects and more active participants from all members projects. I'd like to see a more active organization in general but am beginning to conclude that a fully volunteer "staff" is only going to be able to do so much. In terms of bureaucratic issues, several board members have lobbied hard to spend money to hire full or part time help either in an administrative capacity or as some sort of combination administrator/executive director. For a number of reasons, the board has been reticent to do this but I think it's become increasingly clear that our growth and relevance as an organization is going to require this. I think hiring the bookkeeping service was a good first step. I think at the very least, SPI should "outsource" most of the non-fun administrative work to others so that the board can focus on the important work of advocating free software and helping our member projects. I'm famously concerned with introducing paid labor into voluntary free software projects but I think that, if done right, this could be a very good step. In terms of my own involvement, I'm planning to stay involved as a contributing member or perhaps even as an adviser if the board will have me. I'd like to continue work on the SPI-Trademark committee and look forward to the day that we can create a general policy for helping folks use and license the Debian mark (and other trademark SPI may hold in the future) as permissively as possible. I'd also like to see a better documented process for becoming an SPI member project. This should explain to projects what SPI expects from them (e.g., democratic decision making, an active representative to SPI, etc), what they will get from SPI, and what is necessary to make it all happen. I'd like to work with some of the recent member projects to help document their experience and make easier for the next batch. I'm looking forward to taking some time off and look forward to the possibility of running for a seat on the SPI board again at some point in the future.

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: Example Haskell language benchmark for Lars Wirzenius

I was somewhat curious what the Haskell code for Lars Wirzenius experimental language benchmarks would look like. So I put together a quick implementation of it. It's 69 lines with a lot of comments, 34 lines without comments or type signatures (his Python implementation is 57 lines with a few comments). No, I don't think number of lines is an argument for quality. I wasn't programming for number of lines, by the way, this code is very readable to any Haskell programmer. Try it with the GHC compiler, especially with optimization. It should also work just fine with the Hugs interpreter (using runhugs). Note that this doesn't really address the speed issues that Lars is interested in. I don't know what input he's using anyway. You might want to read the GHC manual about how to write sooner, faster, smaller, thriftier Haskell code. Of course, I think that Haskell is a wonderful language both for serious programming, and for hobbies. Maybe it's the new programming language you should learn this year.

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.

Marco d'Itri: I like receiving (some) bug reports

I suddenly realised that I like receiving bug reports. In a recent bout of structured procrastination I fixed more or less all the bugs I could fix in my packages (except ppp. I don't feel like working on ppp right now, does anybody want to help me?) and now this is a quiet period. Obsessively checking the bugs mailbox for new messages is a clear withdrawal symptom. I am addicted to bugs for a very simple reason: they are a challenge. I stopped working on mutt because it was not interesting anymore to me and then I adopted ppp and packaged udev because I tough that maintaining them would require solving many interesting problems. It's too bad that solving some needs the collaboration of other developers, but this will be the topic of a different rant. But not all bugs are an interesting challenge. Some are just a total waste of my time, which usually is much more valuable than the time of the submitter. I will show some examples.

Obscure bugs which I cannot debug and need repeated interactions with the upstream developers trying to debug them. OK, you submitted the bug and I am sorry that I cannot help more than this, but I told you where you can find somebody who cares. Now please do not expect me to forward emails back and forth from the BTS and upstream developers. This is not only very inefficient for you and for the people who are trying to help you, but also wastes my precious time.
Features to be forwarded to the upstream maintainer. I am a Debian developer, not your personal assistant. Forwarding your feature request, which probably will never be implement because it is crazy, useless or just needs more work than it is available wastes my precious time. And then I will waste even more every time I will be distracted by seeing it in the BTS, and curse you for continuing to waste my time.
Trivial upstream bugs like spelling errors. It is highly improbable that I will consider them important enough to be worth fixing with a patch in the Debian packaging, so what about you do not waste my precious time and just report them to the upstream maintainers?
Requests for useless changes to the packaging. If it is useless and you do not even care enough to implement it, what makes you believe that I will? (Yes, I will decide what is useful.)
Multiple reports about the package being totally broken. If an important package is obviously broken (often broken as in "the system will not boot") then probably somebody else will have already submitted a bug report. It is your duty to check for open bugs before reporting a new one, and merging or closing duplicate bugs wastes my precious time.
Bogus reports showing that you did not RTFM.
Bogus reports showing that you have no grasp of how the package works. Especially if I explained the issue in the README.Debian file.
Unreproducible reports where every clue points to a PEBKAC and the reporter still does not promptly follow my instructions for trying to confirm the bug.

So, if you can follow these simple rules I will probably not flame you to ashes the next time you will report a bug on one of my packages.

3 September 2006

Marc 'Zugschlus' Haber: Why translate Debian stuff to German?

Disclaimer: I am not comfortable with technical documents in my native language, German. I generally find German translations of technical stuff clumsy, overly complicated and badly worded. I might have a “special” feeling for the language, but some output of translators is just too bad to tolerate.For example, I constantly keep stumbling over the german translation of the Debian security team FAQ, which I consider horrendously badly done. Especially the use of the german word “Gutachten”, which basically means “opinion” in the legal sense (as the document produced by an expert called by a court of law) to translate “advisory” is a very very bad choice. My toes curl when I read the german version.In April 2005, I suggested to the German translation team to review the translation of the security team FAQ. I might not have chosen the right wording for that request, but besides a lot of flamage and “the translation is just fine”, I received the usual “send a patch”. Which I did in April 2005.No answer. In October 2005, I asked again, and received answer from the translator that my patch was just too intrusive. Well, a bad translation was rewritten, and the bad translation is still being used.Consequences for me? I’m not going to bother any more about German translations. English is just fine, and when somebody needs a German translation, I’m going to translate the stuff myself. Pointing people to the official German translations is just too embarrassing. A pity.

Marc 'Zugschlus' Haber: Looking for useable CA software

To support my experiments with OpenVPN, I have been trying to evaluate different CA software packages in Debian. With devastating results.I tried

pyca
tinyca
easy-rsa (from the openvpn package)

pycaPros

command line

Cons

Unmaintained upstream
Quite underdocumented - the maintainer doesn’t think so and closed #355177.
Didn’t work when I tried it

tinycapros

seems easily useable

cons

has a GUI and is thus not suitable for very old boxes as CA host
version in unstable gets in endless loop after CA certification
version in testing crashes without error message if default values for CA are changed
version in testing succeeds in creating CA and then displays a GUI that doesn’t accept any mouse clicks

easy-rsapros

easily useable
Only CA tried that actually worked in creating certificates for first OpenVPN installation

cons

not properly packages - only in examples directory of OpenVPN package
creates CA without password!

openca

not packaged for Debian (see #141748)

openxpki

split from openca in October 2005
Has not yet released any code

conclusionAll software sucks. Does Debian have CA software that is actually useable?

David Nusinow: More Steering Committee

I'm glad people have reacted in a largely positive manner to the steering committee idea. It's not really original, but I'm perfectly happy with stealing ideas from other people. I'm going to clarify a few basic ideas here and then address criticism.

The biggest difference between Debian and someone like Canonical or Redhat is that we don't pay employees to do things. We could go that route, but a defining feature of Debian is that it has a bottom-up structure, rather than top-down. I think this makes us unique and we need to do our best to preserve it. I imagine the steering committee to be an extension of this model.

First, the committee would be not be elected by the developers, but would instead be delegated by the DPL. Developers could challenge this delegation in the same manner as any DPL decision. The committee would be very similar to the technical committee in terms of size.

Second, its scope of power would be similar in that it would only relate to the distribution itself, rather than the way the Debian project itself was organized. Its powers would be limited to approving specific improvements within the distribution. These improvements would have to be submitted for approval by the committee, preferably in some sort of specification format similar to the one Ubuntu uses. The committee would then vote on the issue (most likely following the same rules as the technical committee). If they approve it, anyone is free to work on that specific improvement even if it touches on packages they don't maintain. This allows motivated developers to freely work on cross-distro improvements without worry. The committee would ideally be relatively quick to reply to submitted proposals, allowing fairly rapid developments to occur (to facilitate this, proposals must be well thought out).

Further, like the release team, the steering committee would also be responsible for actively working on goals that are set. This would ensure that something actually does get done. These features would give us a group with a limited scope of powers to implement large-scale improvements to the distribution without forcing anyone to do work they don't want to do. In addition, motivated people would have the authority to make large-scale improvements (like consistent theming for example) across many packages they don't maintain. People working on these improvements would be expected to try and cooperate with the normal maintainers as well as possible, so as to prevent problems. Maintainers who have issues can appeal to the technical committee, whose role would remain reactive to solve conflicts as they arise.

Ok, now for the critique from ij, which is a good one. I think the problem with what you suggest is that the DPL simply isn't going to be capable of acting like a good dictator without working full time on Debian for several years. The job is just too big. Allowing them to remain DPL for more than a year is something I don't think many DPL's would opt for anyway, it's just too draining.

The other existing structure is the technical committee, which is a better candidate for taking on this sort of role. The key to the tech-ctte though is that its job is to handle technical disputes. We could expand its role to allow it to set policies and direction, but then who do you appeal to if you don't agree with them? The developer body can override the tech-ctte (with a 2:1 majority) but that adds additional democratic overhead. GR's are draining, and providing another layer for technical decision making allows us to avoid them. Further, I'd like the steering committee and tech committee to have different modes of working. I imagine the steering committee to be more agile, taking a leading role in setting out a vision for the mass of developers to follow and take inspiration from. The tech committee, on the other hand, should be more defensive, carefully deciding on the most difficult issues. Basically the steering committee will looking towards the future, the tech committee will be looking towards the present.

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.

Scott James Remnant: Having Left Debian

It’s been over a year now since my last proper upload to Debian, and nine months since I announced my intent to put aside working on Debian for a while. With Matthew Garrett’s resignation from Debian, several people have compared it to my own “resignation” from Debian. It has got my thinking about whether I currently intend to ever end my “Sabbatical” and return as an active Debian Developer. I think that the end of my love-affair with Debian started at Debconf last year where several developers treated those of us who also worked on Ubuntu quite rudely. Someone was attacked for wearing an Ubuntu t-shirt at the conference, while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt. That’s where I realised that maybe I didn’t have as much in common with these people as I thought I did. I still don’t understand why Debian singles Ubuntu out for this kind of treatment, we’re still the only derviative distribution that makes all of our patches to Debian available, yet Ubuntu is claimed to not do anything at all. Another example is that Ubuntu is being asked to change the Maintainer field of every package, something no other derivative is being asked to do or has ever been asked to do. Martin Krafft has had some interesting things to say about this strange relationship in the past. If that was the start of my falling out with Debian, I think that Debian considering removing documentation and firmware from the distribution, especially the documentation, was another point I started wondering whether I shared anything in common with the project anymore. Call me strange, but I think that one of the fundamental purposes of a Linux distribution is to be useful to its users. If nobody can use the distribution because it doesn’t support their hardware, and even if it did, all the documentation has been stripped out; I started to wonder what it’s aims are. It became increasingly apparent that the only users Debian was considering a priority were its own developer. And the third thing is simply a matter of Fun. Fun for me, at the moment at least, has been to build a system that fits together extremely nicely with each component doing the right thing. For Ubuntu this has meant being a driving force for it being Linux 2.6 only, with reliance on udev for hardware, etc. Upstart is just a continuation of these goals, getting a system which all “just works”, even if it means throwing out a few things people were previously fond of. All of these things would have been impossible to do in Debian itself. Getting upstart installable required changes to twelve different packages, including sysvinit itself; at a worst case, this would have required the agreement of twelve different maintainers in Debian. It’s often exhausting just persuading one of the reason for the change, persuading a dozen would have been a herculian effort. Perhaps Matthew is right, what Debian lacks is a single leadership. There’s nobody in Debian I could have gone to for approval over the changes I wanted to make, whose decision developers cannot overrule. Ubuntu has such people (the Technical Board and sabdfl), which gives the project an obvious direction instead of a couple of hundred people all pulling in different directions. In a way, I don’t feel that I’ve left Debian. I feel like I was happily going along, only to realise the mob had gone in a different direction and with no easy way of rejoining the group.

Antti-Juhani Kaijanaho: Haskell responses for Eric Warmenhoven

Eric Warmenhoven asked a couple of Haskell questions. Here are my answers. BTW, do you want to be added to Planet Haskell? If so, drop me an email. Also, be sure to subscribe to the Haskell mailing lists. Where did all the shared libraries go? Turning a Haskell module into a static library looks like it s fairly straightforward, but it looks like it s impossible to create a shared library that s usable by other Haskell programs. See the GHC FAQ. Why do header files have a bizzare suffix? If module A uses something from module B and module B uses something from module A, there s a circular dependency that GHC can t resolve on its own. The solution to this is to create a boot copy of module A that defines the things that B depends on without depending on B. In C this is called a header file. In GHC this is called a boot file and is given the extension .hs-boot . There are no header files with Haskell. Or rather, there are (the .hi files), but they are generated by the compiler when compiling the module. The .hs-boot files are not header files but a workaround for GHC’s inability to compile circularly dependent modules (which the language spec requires). Why does everyone ignore all the practical stuff? I read through five tutorials before I finally found one (on Monads, of all things) that actually had a usable getArgs example. Perhaps many people consider the practicals easy and want to discuss the hard things instead. Where s the Debian-specific documentation? For example, there s a GTK module. Where is that? How do I get it? Is there a package for it? If not, how do I make one? (I saw the debian haskell mailing list but didn t feel like wading through the archives hoping that one of my questions might be answered.) There is no Debian-specific documentation apart from a draft “policy”. Googling, I found this repository that contains Gtk2HS debs. Haven’t tried them, though.

Eric Warmenhoven: Monadic

All I have to say is, damn you Evan. Back when I was in college (six years ago), I took CS 162, “Programming Languages”, which was a required course but I would have taken it anyway. Most of what I remember focused on explaining the features of the languages we already knew (Java and C++) and explaining that things didn’t have to be that way. They introduced Generic Java (I hear generics have been added to Java now) and had us write several programs using generics, which was about the only language that we actually had to program in. But they also made us use Haskell. As I recall, the assignment in Haskell was to write a B-tree. We didn’t have to compile anything; we just wrote a small file and loaded it in hugs and ran commands in the interpreter. It actually ended up being really easy, which left a favorable impression of Haskell in my mind, but I never learned more about Haskell. Instead I went off and learned C by hacking gaim. And look where that got me. Anyway, over the last year or so, Evan Martin has written about Haskell fairly frequently, and every time he does, it brings back fond memories of my earlier Haskell programming experience. And two weeks ago, I finally decided to do something about it. I downloaded hugs and GHC and read a lot of documentation, and wrote a lot of test programs. This time, with the aid of GHC, I actually compiled an executable. And it was fantastic. Suddenly Haskell became a real language for me. Though it took a lot of reading first to figure out how to get the list of command line arguments, and then to understand how the IO Monad works so that I can actually use the getArgs function without screaming. So here I am, a Haskell newbie coming from a C world, trying to make sense of it all. And naturally, I have questions.

Where did all the shared libraries go? Turning a Haskell module into a static library looks like it’s fairly straightforward, but it looks like it’s impossible to create a shared library that’s usable by other Haskell programs.
Why do header files have a bizzare suffix? If module A uses something from module B and module B uses something from module A, there’s a circular dependency that GHC can’t resolve on its own. The solution to this is to create a “boot” copy of module A that defines the things that B depends on without depending on B. In C this is called a header file. In GHC this is called a boot file and is given the extension “.hs-boot”.
Why does everyone ignore all the practical stuff? I read through five tutorials before I finally found one (on Monads, of all things) that actually had a usable getArgs example.
Where’s the Debian-specific documentation? For example, there’s a GTK module. Where is that? How do I get it? Is there a package for it? If not, how do I make one? (I saw the debian haskell mailing list but didn’t feel like wading through the archives hoping that one of my questions might be answered.)

1 September 2006

Andree Leidenfrost: linux.conf.au

linux.conf.au will be held from 15 - 20 January 2007 in Sydney, Australia.

Hopefully, Bruno and I will be given the opportunity to share with others our experience with upstream/downstream maintenance of Mondo Rescue. The presentation we have submitted about this is called "Mondo Rescue & Debian - an Example for Upstream/Downstream Collaboration".

It would be positively fabulous to actively participate in the conference and to be surrounded by people that share the same interest in FOSS. And meeting Bruno in person would be cool, too - after all, we've worked quite closely together for a year now without even speaking to each other. Maybe we'd even get some hacking done! ;-)

I am excited!

Next.

Previous.