Search Results: "zed"

4 September 2006

Dann Frazier: Trying out hula (0.1.0+svn379-2.1)

I'm always on the lookout for a better way to maintain and share my calendar. I currently have a hybrid solution - evolution/webcalendar. I use evolution to store all of my HP appointments, because it can easily import ical appointments. It also has a pop-up reminder mechanism, which is certainly a must. But what sucks is that I want to see/be reminded of the same appointments whether I'm on my laptop at home, or in the office on my workstation. evolution doesn't share its calendar with other clients. Outside of work, I use webcalendar - which is actually pretty feature rich. It can send e-mail reminders and even has a .ics interface that evolution can poll. That way I can overlay my (read-only) webcalendar appointments on top of my evolution calendar, so I only have to maintain those appointments in a single place, and can still get pop-up reminders. Unfortunately, this hasn't been working with recent evolutions - and when it did, it was flaky - random crashes, etc. A problem with webcalendar is that everyone I invite to an event needs to have an account. I want to be able to invite anyone in the world, with just their e-mail address. When I'd first read about hula, I let my mind go wild with how it might work. Wouldn't it be cool if this was just a simple to install/configure/use client that people could just install and run locally? And then what if all these clients could somehow be organized into useful groups? Like I could tell my client that I'm an HP employee, and it could talk to some hp hula server to see my coworker's schedules? And I could also see my buddy's calendar that lists all the concerts he's going to this month, by communicating with his client directly, in an rss fashion? No required central server, just a client that knows how to collect/post information in standard formats and present it in a useful way. Well, that's not what hula's all about, it seems. It looks very centralized, and isn't something many of my friends could configure themselves. I installed sid's hula today; which is admittedly about 6 months out of date. I was initially impressed with the ease of install & the pretty web page, but quickly became disappointed by the admin architecture. Adding a user is terribly, terribly non-intuitive. And the whole thing looks overly complex, like its inherited a lot of design cruft. But, once you log in as a user, things look fine. hula's calendar looks nice, and I'd seen a flash video that makes newer versions look really spiffy. So, I wanted to see if I could easily import an e-mailed invitation into it. This means I'd need to give hula access to my e-mail. You can have hula pull mail from a remote server - I was hoping to connect it to my imap server as a read-only client for this test. However, it seems that hula will only pull mail every N hours, where N is configurable globally. I really just want to have an active imap session, using hula as a front-end, but that feature doesn't look like its there. I also couldn't find anyway to import an existing calendar/.ics file. Anyway, I've seen enough to know that hula isn't going to work for me yet. It doesn't appear to offer me anything that I don't already have, or simplify anything I do already have.

Fumitoshi Ukai: Upgrade to sarge at Kashiwa NOC

Today, mrmt, ishikawa, kmuto, Ar-, nnn went to Kashiwa NOC where some Debian JP servers and JLA servers reside. They upgraded their servers to sarge and I, from my home remotely, upgraded Debian JP servers, JLA servers and my server to sarge and kernel with help of them. misato.debian.or.jp: this is old server. backup necessary files/data and recalled. plat.debian.or.jp (debian archive mirror): this leaned in the rack (maybe due to the earthquake at Kanto area recently). Shutdowned and relocated. IDE controller was somehow broken, so other old server is used as replacement. While replacing, /dev/md1 was broken. /dev/md1 is partition for debian archive mirrors. I tried to fix it. At first, I fix partition type of hdb1 (Linux -> Linux auto raid detect) and recreate md.
 # mdadm --create /dev/md1 --level=linear --raid-devices=2 /dev/hda1 /dev/hdb1
Then, I could fsck on /dev/md1. However, many inodes were broken, so it seems a lot of time to fix it (note that still fscking snapshot.debian.net old archive disks (1.4TB) for 40 days...) All contents in the partition was just mirrored contents, so I recreate the ext3 filesystem and mirror from upstreams. It would take 1 day or so to recover full mirrors. arashi.debian.or.jp (Debian JP web/mail server): After upgraded sarge, kmuto upgrade the kernel to new version. He rebooted but no response. He finally found that VGA card was broken. He replaced VGA card from recalled server (misato.debian.or.jp) and it worked. I noticed upgraded dancer-ircd couldn't communicate with older version of it. (claimed failure to match password). So, I upgrade all of our servers in our IRC network. minori.linux.or.jp (JLA backend server) and norika.linux.or.jp: I upgraded them to sarge. Except dancer-ircd problem as above, the problem (reported by takei) was that customized cvs pserver line that I put in inetd.conf was disabled by cvs package. I re-enabled it. These works took 5 hours, and still mirroring.

Fumitoshi Ukai: hyperestraier 0.5.2 deb package ready

New upstream version of hyperestraier 0.5.2 has been released. This new release includes Java Node API of Hyper Estraier. I debianized this and put sarge version on http://people.debian.org/~ukai/hyperestraier/ . Since ftp-master.debian.org is still not available, I'll wait upload hyperestraier 0.5.2-1 until hyperestraier 0.5.1-1 gets in NEW.

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: 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.

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: Defining Free Content and Expression

(This is mostly reposted from an Advogato article I just submitted).
About a year ago, I posted an article on Advogato entitled, Towards a Standard of Freedom: Creative Commons and the Free Software Movement. In it, I argued that Creative Commons and the free culture movement were struggling to build a cohesive freedom movement in the way that free and open source software had succeeded in doing by never stopping to define the ground rules of the commons movement. I argued that Free Software built a movement around calls for essential freedoms and against the actions of software producers who failed to live up to this standard. On the other hand, Creative Commons has argued for "some rights reserved" but never explained which rights were unreservable. In the process, they've done the invaluable service of creating a stable of powerful, internationalized licenses. But they failed to build the type social movement that some of us wanted. While this was never their goal, it left some people unsatisfied. In a later version of the essay published in Mute Magazine, I concluded by stating:
Whether in unison or cooperating in separate groups, it is time for those those of us that feel strongly about freedom to discuss, decide, and move forward with our own free information movement built upon a standard of freedom. When we have defined free information in terms of essential freedoms, a subset of Creative Commons works and a subset of Creative Commons licenses will provide tools and texts through which a social movement can be built.
I'm thrilled to say that that day is now within sight. A few weeks ago, Larry Lessig introduced me to Erik M ller, a Wikipedian who had read my article and was planning on launching the same project that I had been planning. It only seemed sensible to collaborate. Today, we have launched a draft of a Free Content and Expression Definition online at freedomdefined.org. The website is a wiki and we welcome feedback, suggestions, and alternative versions of the document. So far, we've have decided to stick closely to the freedoms of free software but are actively interested in updating these to be more relevant for other types of creative works. Of course, anything, even the name, can be changed at this point. To guide us through the project of debating and further refining a definition are four moderators who will ultimately be called upon to resolve disputes and disagreements about what the definition should and will say. These moderators are myself, Erik M ller, Creative Commons General Counsel Mia Garlick, and Wikimedia Foundation Trustee Angela Beesley. You can view the announcement of the definition, please take a look at: To view the definition itself, please visit:

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.

    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.

    30 August 2006

    Joey Hess: id fraud

    I found out today that someone found the small amount of information about me they needed to nearly successfully buy stuff in my name. They call this "identity theft", but since my identity still seems to be intect (pats his rampant ego) and since as an ardent SF fan, I'd like to reserve the term identity theft for the possibility of someone stealing a copy of me, I prefer not to use that term for this form of fraud. Luckily I already had a fraud alert placed on my accounts before this happened; I started placing these alerts a while ago, on the basis that the banking system's verification methods are so broken that it makes sense to just do it pre-emptively, before you have any reason to think someone is trying to defraud you. Who knows if that does any good though. Oddly, I almost ranted about this id theft nonsense last week, before I knew this happened. The thing is, while I'm calling to report credit cards as compromised and learning that someone managed to put together my name, address, phone number, and a not very well secured credit card number; at the same time I have something here with these properties:
    1. Anyone can use it to verify if a given statement (such as "transaction #128: please pay this person $500") was actually made by me and actually applies to the person I meant it to.
    2. Using it doesn't automatically give it to a supposedly trusted third party, such as the low-paid phone support guy who has my credit card number and all the rest up on his screen right now as I ask him to cancel the purchase.
    3. According to the experts is not breakable by any means except for a brute-force attack that would use the resources of a medium-sized country.
    4. Can be used to identify me with a fair degree of certainty, even if you've not met me.
    5. Is suitable for use on the internet.
    6. Even if physically stolen from me is not trivially easy to break and use.
    7. If I lose it or know that someone has stolen it from me, I can revoke its use in a way that is just as hard to forge or break.
    8. Can, incidentially, be used to make private conversations just as hard to snoop on. But that's probably a different rant.
    That magic thing is a public and private key pair for GPG, and it seems really weird to me that I can use this for unimportant things like signing email, and for crucial things like authenticating changes to the software deployed on millions of coumputers, but I cannot use it to pay a bill. I wonder if the world at large will ever catch on to the uses of public key cryptography? Anyone want to start a First Bank of GPG?

    29 August 2006

    Joachim Breitner: Free Software Club continues

    Today was the second meeting. At the first meeting, I introduced a wiki and a blog, but so far they have not been using it a lot. To change that, I will now reward "Geek points" for contributions in the wiki, and on the blog, as well as for other challenges. The topics today were how software is created (quick overview of the priciple of compilation, and mentioning of the need for documentation etc.), and then I continued with Free Software: What's wrong with proprietary software, and why Free Software is better.I think they got the message, but are not fully convinced yet. It seems that they found my "Hello World" demonstration in Python, Perl, C and Haskell more interesting, and my offer to do a little programming course in the club was well received.A bit worrying are the questions "Can you hack into this sytem?", "Do you know how to hack through a firewall?" Of course I can't just say "no" (it would be discouraging) or "yes" (then they would want me to show how, which I don't want do do yet). I tried to explain then that to be able to "hack through a firewall", you first need to understand what a firewall is (Knowing that it is something that blocks unauthorized access from the outside is not enough), and then how it works in the details. Basically I tried to tell them that knowledge comes before any hacking (or cracking).You can have a look at the slides, comments are of course welcome!

    Erich Schubert: Keeping your users out.

    Today I was trying to find some information in the Ubuntu forums. I'm seriously annoyed. There was one thread that seemed relevant, but it has some 310 pages. Yes, thats over 3000 posts. Unfortunately, Ubuntu (and I consider this arrogant behaviour) doesn't allow you to search the forum or access attached images if you are not registered. I can understand things like spam protection. But WTF do you require registration for searching? I mean... I was trying to find out if the Ubuntu community could help, and all I get is "register first"!? Thats pure harrasment of non-registered users. I don't think I'll bother to remember another username and password just for their crappy forums. I hate forums anyway. And the size of that thread just shows that forums don't scale well. Especially if you can't search. [Update: yes, I've been a bit harsh here. The front page says that they're experiencing speed issues, and thus have disabled search within the forum. Actually I can't believe that search requests make such a huge load (especially compared to me browsing a 30-page thread...) - but maybe their search function is just implemented badly? I wouldn't be surprised if they do some huge SELECT to search, and don't have an index optimized for text searching. Maybe they shouldn't be using a closed source software for running their forum. I guess they could just fix the search functionality then. If opensource software doesn't meet their requirements, they're bound to get some support by the community to make the software meet them, if vBulletin actually is better in some points. IMHO vBulletin sucks. And given the speed issues "it is what the admin prefers" might miss some important point - that at some point you can't just keep getting a larger CPU]

    28 August 2006

    John Goerzen: Renovation: Weeks 8-9

    We've been very busy lately, so I'm a bit behind on renovation updates.

    I've posted the photos for weeks 8 and 9. The new kitchen is starting to take shape!

    We're also going to get a nice heating/air system. My great uncle, who is doing that work for us, came up with a 3-zone system. We'll have one furnace & AC, but three temperature sensors. There will be motorized dampers in the ducts that are controlled by that system, so we can direct hot or cold air only where it needs to be. We'll break even on it now because we can make do with a smaller AC and furnace, and will save money over the long run due to lower utility bills.

    We also learned that the wood floors in pretty much the entire house can be saved, so that'll be nice, too.

    Here's a sample:



    Click here for the rest.

    24 August 2006

    Marcela Tiznado: Debian Day Uruguay

    After some days of thinking what should I do, I finally decided to go to spend 1.5 day in Uruguay to attend to Debian Day organized by Debian-uy. The trip was quite long (~7 hours) for being so near to Montevideo...



    some could rest, some others didn't :-( After the boat we still had 4 hours on a bus. When we arrived we had some coffee while waited Debian-uy people to pick us.



    We finally got picked and took us to the Instituto Tecnico Superior where Debian Day was going to take place.
    The event was much more that what I've expected on amount of people, specially cause was the first "big" event organized by this group. There was a hacklab where people could attend with their computers and get Debian installed, they also offered people copies of Debian CDs (some people got the Sarge DVDs that remained from DebianDay-mx), hacking place, and of course somewhere to get "mate".
    The talks were quite good in general, some where general free software and some others specifically about Debian. I signed keys with few people. The atmosphere was great. Thanks all Debian-uy for the receiving us.

    On the way to Rodrigo's home, we found drummers playing along the street with huge flags and people dancing around. Simply amazing to found one of those non-tourist events.

    23 August 2006

    Matthew Palmer: That's one way to put it...

    This pretty much accurately expresses my gut feeling of what Ruby is:
    ... pretty much a Perlized dialect of Smalltalk... from http://c2.com/cgi/wiki?SmalltalkLanguage

    Amaya Rodrigo: Murphy's Power Supply

    Short summary: Server down.

    Isn't Murphy absolutely lovely? Hardware will, of course, break on weekends.

    The light in my kitchen's ceiling stopped working a month ago. I changed the light bulb, a week ago, but it didn't help, so on Friday I asked H ctor to take a look at it. Absolutely low priority. The cable was literally roasted, so he asked me to cut the power off, in order to replace the cable. I did, without remembering to propperly power off the server. What are journalling filesystems for anyway? The UPS battery used to perform much better, oh the decay, so the server is abruptly shut down after a couple of minutes. As H ctor was not able to "quickly" fix the kitchen light, and I was not in a hurry, and do not really care about the damn light, we just didn't look at it any further. So far so good.

    Some hours later, at midnight (maybe that's technically Saturday, but it really felt like a Friday, I swear to the allmighty vegetarian spaghetty monster with no meat balls whatsoever), I try to power the machine up. And a sadly familiar ritual is about to be performed. Since I moved the server into "the run down attic I call home" I dreaded the moment I had to reboot the machine. It would come up, you could see the blue case fans light up and spin, the hard drives and CD drives be initialized, but no beep, no POST, no nada.

    Aenima, my solu, my baby, my serverThe ritual dance would consist of me submissively kneeling down to power on and off in a random sequence the back switch, the front one, the UPS, the reset buttom, curse, turn it completely off for random amounts of time, pull the cable in and out, curse some more... never really finding out when or what would make it fully come to life. But eventually it did, after 5, 10, 15 minutes, without any reproduceable pattern, it did. Not on Friday night. Or saturday. I spent most of the night (until 6 am) performing the ritual, googling like crazy, fustrated and eventually plain angry. All I could find was "the mobo is b0rked, exchange it". But I knew it was not. I knew the CPU was fine, the MoBO was fine, the memory was fine, because when I finally managed to get it to power up, all worked well!

    But Miry came home and helped me out, coming up with a valuable clue: The mobo was not getting enough power form the PSU, so I got a spare PSU from H ctor and swapped them. The baby came up instantly. So I was very pissed off.

    The good thing about it all is:
    - I learned that power supply units sometimes fail. Even my wonderful, 100 EUR BQuiet! PSU.
    - I missed completely all of the udev fun. Well, at least on my machines, but there's a couple of people I needed to help out today.

    On Monday I got a new power supply, it is a joke of a plastic, for SM's sake! plastic!?, PSU with a couple blue fans. Pics of old nice one and crappy new one here. My sitting room looks like a space craft, and sounds like a plane is about to take off. The cats have not complained yet. They have not disconnected my land line (yet).
    Update: The reason I bought this PSU is I have quite a big case, a case I can ride! So I needed Log cables. And I had to go for a cheapo modder plstic thingy, simply because I could not afford anything better.

    I hate hardware.

    New and old PSU

    Amaya Rodrigo: Firefox, the browser aliens prefer.

    Next.

    Previous.