...

Leaving aside the obvious failure (asking women to classify themselves into those who are happy to have their breasts groped and those who aren't - and yes, that is the effective choice, since refusing to participate will result in people making conclusions about which of those categories you fit into), there's the whole "open-source breast" thing.

Creating copyrightable works is a choice. Having breasts is not[1]. Attempting to equate the two is not reasonable. Applying "open-source" to things that are not directly comparable to copyrightable works is like applying "Darwinism" to things that are not directly comparable to natural selection operating upon living things. Discussing Darwinistic politics is likely to result in people concluding that you're either a libertarian fuckloon or blame atheists for the death of your cat. Discussing open-source breasts is likely to result in me stabbing you in the fucking eye. Don't make the baby Jesus cry when he sees your horribly mutilated face. Just accept that open source is a useful licensing model, not an entire way of life.

Or: get your hands off my adjective or you'll find my hands on things you really don't want groping, whether you're wearing a badge or not.

(And yes, I realise that this is not the offensive aspect of things. This says it better than I could)

(Previously)

(Previously previously)

[1] There's a set of basically uninteresting exceptions. And by "uninteresting" I mean "If you are trying to argue over this, then you are missing the fucking point"

Funny how technical people always seem to search for technical solutions to social problems. "Some people think there's too much content on Planet Debian. Let's create another Planet with less content, that will solve the issue" Allow me to just say: "Hah" Planet Debian is a website with a lot of content. If you read such a site, inevitably there's going to be some content you're not going to like. This is a fact of life. Reducing that content so that it no longer carries the content you personally don't like might solve the issue for you, but there's no guarantee that it will also solve the issue for everyone else. For instance, I know I don't generally like Russel's writing style, but I don't assume that's the case for everyone else. It would be silly for me to request his removal from Planet Debian for that reason alone. If there's stuff on Planet Debian you don't like, then just don't read it. That's easy enough... and if it isn't, fix that!

Well I did not expect that much when MySQL offered us to piggyback on their participation in GSoC 2008, but at the end we have two projects. One is about blobstreaming which I absolutely don't know and is probably some amazing new technology :-). Marc will act as a sponsor on this together with some guys from http://www.blobstreaming.org. The second project is setup rewrite where I will act as a mentor and Piotr Przybylski will implement it. Hopefully we will bring this to successful end and soon phpMyAdmin will bring you easier way to set up and configure it's options.

I originally had the idea for a list to keep track of stuff that doesn't work with Linux something like 12 years ago. I built an initial version, that proved reasonably popular at the time, but then the place it was hosted had some problems, and I was busy with other things. I finally got around to building a new version four or five years ago, and it's been doing ok since then, but with a baby on the way, I've been thinking of things to get rid of, and this is not something I do active work on, so maybe it would be best to find a new home for the site, located at http://www.leenooks.com. Here's the catch:

• Whoever gets it has to promise to maintain it as essentially what it is today - you have to continue to provide information about hardware that does not function with Linux, or only functions with proprietary drivers.
• It does generate some money, that I put towards the server where it's hosted. I wouldn't mind selling it for something, which will hopefully encourage only those truly interested to apply. It could probably generate more money if it were plastered with a bunch of ugly ads, or, hopefully, if more time and effort were put into it than I have at the moment.

It currently runs on my own server, and uses DedaWiki, an open source, Rails-based Wiki, as well as PostgreSQL. You would have to relocate it to your own server. So, if you're interested, contact me: davidw@dedasys.com. If I don't find the right person, no worries; I'll keep maintaining it for a while yet.

The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:

• All Virtual All The Time (AVATT):

This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.

SCSI booting in coreboot:

Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.

This should make for an interesting summer with nice improvements for coreboot.

The packages is already done, thanks to Bradley Smith for the patch, you can find it here.I'm working right now in the unstable versions but the GCC 4.3 issues remains, in rtorrent there seems the issue isn't solved with the actual patch but libtorrent does, I will ask someone to upload them to experimental as soon as I get something ready.

Test successful: the new (and very nice) Apple keyboard (the wired one, if only because I need the numeric keypad regularly) is coffee-safe. Incidentally: Anyobdy has instructions for mapping the “fn” key to function as an insert key? On the console, it produces 00 83 d0, but in X it doesn't send anything (according to xev). Comments welcome. (Martijn proposes to use F13 instead, which I guess I'll do meanwhile.) Update: Hmm. Seems I lost the s key. q, a and y also stopped working for a time but are back again. I hope s will dry out soon, I need it. (and y is again not working. Drat.

[Warning, long post ahead. If you aren’t interested in Debian or it’s internals or my work - skip it. :) ] So as you might have read here, I got the delegation of the debadmin AKA FTPMaster group lately. I’ve got some pressure to not accept this delegation, but the response to my blog post about it had been extremely positive, everyone said I should not deny it. Knowing to have such a support within Debian is something I really appreciate, making it worth to spent time on my various jobs. Now, lets take this and write a little about what happened since I gained that extra group:

• Aj resigned from anything that requires additional group privileges. (As a DD run id ajt on a debian.org machine if you want to verify this).

Work I did since then:

• One of my first action was to finally finish the release transitions support, something which was waiting for it’s final merge for a long time. The release team was waiting for this and did ping us (ftpteam) multiple times, but now it is there. You can read more about this feature in my list mail and my initial blog post. (Oh, and something I have missed about everywhere I wrote about this: This whole transitions thing is based on an idea from Marga!)
• Added a mapping in dak, requested by Luk
• Merged a patch from another ftpteam member, Thomas Viehmann, which fixes daks handling of Format 3.0 (something) uploads. Currently it rejects them, without the merged patch it just crashed.
• Changed our daily cronscript to no longer VACUUM/VACUUM analyze projectb in every run. Postgres >= 8.1 has autovacuum, and its turned on, so we should be fine without extra runs of it. (And while i write daily cronscript or cron.daily - I mean dinstall, right now run twice a day).
• Fixed a breakage in code introduced by Debian maintainers which led to process-accepted (one main part of the daily cronscript) breaking. It was triggered by some octave-$FOO package upload, where the ###censored### did add someone twice into the Uploaders: field. Not helpful, but now we ignore this case and just warn us.
• Added a script to expire old database dumps. We do dump our projectb (the main archive database) twice in every run (beginning/end), which made 4 dumps a day. While old dumps seemed to have been removed on an irregular schedule - the dumps took about 71Gb in total. Which pretty much filled up merkels /org, as they get synced there. Now, my script (reworked version of a script from Florian Reitmeir) works with an “incremental deletion” scheme:

  RULES = [ ‘days’:14, ‘interval’:0 , ‘days’:31, ‘interval’:1 , ‘days’:365, ‘interval’:31 , ‘days’:3650, ‘interval’:365 , ]

  That means we now keep all files from the last 14 days. Then keep one per week. Then one per month and finally one per year for up to ten years. All the rest gets deleted. Space usage of our dumps now: 4.8Gb. Thats 66Gb gained. Source is in dak bzr if you want it, MIT licensed. If you improvie it further I love to see patches.
• Changed the way the projectb copy on merkel gets synced. Up to now it was run from a cronjob which syncs a number of files people want to see on merkel, including the database dumps, then reloads the database using the latest dump. This was run at a “random” time, scheduled to be shortly after dinstall. Problem with such a setup is that it will miss extra dinstall runs and also might import old data, as the timing of the cronjob meant it runs while dinstall on ftp-master is still doing its work. So bad bad. It is now done using the ssh trigger feature I described a while ago. So our daily cronscript now tells merkel when it should sync its database again.
• Coordinated with the qa group we now also push them, when the sync on merkel is done, so they can kick their cronjobs to reread projectb and just run whenever they get told that something changed. Yet another bad timing eliminated. (Well, will be done today). Oh, if you have something that depends on information from projectb / ftp-master and try to schedule it to run after dinstall - talk to me, we might just push you too.
• Started talking with the release team how britney, the script which manages our testing distribution, should be handled in the future. It currently is run fully under control of us ftpmasters (and reading hint files from the release team). Ideally this gets changed so that the release team has the control of the code and whatever gets run with it and then, in some way, maybe using ssh triggers, tells us to import a new dataset for testing. That needs some thinking, as obviously it should be limited to testing and we should make sure it doesn’t break the archive, but I think that is doable.
• Prepared a patch that sanity checks the Provides: field, something we currently don’t do. Mailed our internal team address about 3 days ago, to let others look at it, no response yet.

The above should nicely sum up my work in the past few days. Most of it pretty trivial, but still things that have to be done. I plan to keep doing things, slowly going from the trivial stuff to more complicated ones, but there is lots of stuff ahead. Some ideas, and this is a very incomplete list just from my head, there are tons of things that one could do, include

• Finally allowing dpkg-sig support in .deb files. I once, years ago, made a patch for it, which never got applied. (Mostly my fault here). Need to rewrite that to fit the actual code.
• Add a few more sections to our archive. There are multiple bugs asking for them, and some others also come to mind. Like java, ruby, octave, haskell, debug to name a few, but there might be more needed. (Yes, longterm all sections should die and be replaced with debtags. I just don’t think debtags is there yet?!)
• Maybe finally drop m68k and add other architectures to the archive, like some $foo*bsd one. (Thats for after lenny of course, at the time arm also gets dropped).
• Merge a patch I got from Myon which will keep uploaders in projectb.
• Enable bzip2 support for sources, not only for the binary packages. I have a patch ready, it’s not yet merged. Needs to test if anything breaks in stable if we apply it, before we can think about it. Worst case it has to wait until we are running lenny. (The archive runs on a machine with stable, so allowed features always have to be supported in stable).
• Process the currently waiting requests for pseudo-packages and either reject or approve them. After thats done - talk to the BTS maintainers to hand the management of pseudo-packages over to them, as 99% of the usage of those is in the BTS.
• Get dak to optionally mail the sponsor of a package too, if not already in the list of those getting a dak mail. Which isn’t easy. One proposal is to just look at the gpg keyid and get the Debian uid from it, send mail there. I don’t want this, as people are, unfortunately, able to disable mail receiving for their @debian.org address. Which would give us lots of bounces. No way we like that. Similar problems with “Just take one userid that looks like a mail address from their key”.
• Improve various parts run by our daily cronjob, as that one takes ages (about an hour today). Speed improvements are always nice there.
• Think about having more dinstall runs a day. Like - every 2 or 4 or 6 hours could be nice. But that needs discussion within the ftpteam and also with the mirror people before it can be done. But 6 hours seems to be something nice to have, more might be also ok.
• Coordinate with DSA to enable the continous AKA WAL archiving for our database.
• Make merkels sync be more instant, ie. no longer rely on a push of a database dump whenever dinstall run, but something thats near realtime. Having changes done on ries immediately synced to merkel.
• More (active) ftp-team member, maybe?!

Now, do you have any time to kill? Do you want to help? Some things you could do:

• Go look at our bug page and start there. Someone, I think Don, already started using user categories. It would be nice if someone is willing to keep up with the bugs and put them in categories. And continue to do that in the future.
• Generally help with our bug page. One nice task some people do, and possibly more could also do, is retitling bugs. Especially removal bugs tend to have a wrong title. The format is pretty specific…
• Feel free to submit patches to me. I promise to look at them without too much delay and at least give you a hint what might be wrong or could be done better. And if it makes sense, doesn’t break the archive, works, and is something dak should have - I will also merge it. Of course trivial patches are way easier in that regard, non-trivial ones should go via our ftpmaster address first, to leave others a chance to comment on. Bonus points if you provide bzr trees one can merge from, and the bzr tree you should work with is http://ftp-master.debian.org/bzr/ftpmaster-dak/ - patches/bzr trees against outdated versions won’t have much luck to get looked at. :)
• Keep me happy. However you do it, just don’t hug me. :)

I am very excited to announce that Jonathan Roes has successfully applied to the Google Summer of Code 2008 and will be working on netconf over this summer. With his help, I am confident that netconf 1.0 in Debian lenny is no longer a dream. Jonathan is a soon-to-be computer science graduate from the University of North Carolina at Charlotte, and his application was (by far) the most convincing of the ten I received. He has several years of programming and Linux experience and it s quite obvious that he has understood the philosophy of netconf. I am looking forward to working with Jonathan! NP: Underworld: Second Toughest of the Infants

When I code, one of the tools I use which I like the most is GNU screen. My current project involves the editing of a bunch of different source files, and often jumping frequently between them. I was spawning windows and trying to edit files that I had already opened in a previous screen, and often ending up with a bunch of windows with files I wasn’t using much at the time. So I did some research on how to optimize use of vim and screen together. The first thing I came up with was getting screen to display a nice bar at the bottom by adding this to my .screenrc: (Thanks, Red Hat Magazine!) hardstatus alwayslastline
hardstatus string '% = kG [ % G %H % g ][%= % = kw %?%-Lw%?% r (% W %n*%f %t%?(%u)%?% r )% w %?%+Lw%?%?%= % g ][% B %Y-%m-%d % W %c % g ]' This gives you a neat and coloured (mmmm… colours…) status bar at the bottom of your screen display, including some info on whether other terminals are attached to that window and such. One thing which would vastly improve the usefulness of this would be if I could get vim to set the screen window title. The escape sequence for doing this is the same as for other terminals, but vim’s terminal information database does not include the relevant entry for the “screen” termtype. So (with help from “frogonwheels” and “godlygeek” in #vim) I put an entry in my .vimrc specifying the escape codes for setting screen’s window title. In addition, I abbreviated the window title string to contain only the file. Here is the relevant snippet from my .vimrc: if $TERM=='screen'
exe "set title titlestring=vim:%f"
exe "set title t_ts=\<ESC>k t_fs=\<ESC>\\"
endif A casual glance at my school grades chart will immediately reveal that I am not a structured learner; I’m not the type of user who will, when adopting a tool, begin by reading the manuals. I’m more of a gradual, ad-hoc learner, and I tend to prefer to stick to the defaults whenever possible. Since vim and screen are probably my primary tools for doing work, I should probably do some more research on things like this. These suggestions may be somewhat trivial, but I’ve found them to be quite useful, so I thought it might be useful to someone. Please leave a comment if it was, or if you have any comments (duh!) or suggestions.

The Summer of Code wiki page in the Debian Wiki has been updated with an overview of the projects that made the race for the 13 slots we have.A separate press release (containing a short paragraph on what each project is about) is in preparation and will be out soonish.

My previous post has led to a new name and a lot of improvements in the codebase. estron is the new name for DWI. With help from ikiwiki and Alioth, estron has a new home, a new wiki and a fresh start. I've implemented -Werror fixes across the codebase (with the sole exception of some old Gtk2 code that is now deprecated).

As is my regular practice, make distcheck is now working (although some actual tests need to be added) and I've added versioned symbol support. estron can work with libqof1 but it will be better served with libqof2 and that's probably for the best as that means I have time to finish estron to coincide with the libqof2 transition after Lenny. As mentioned in the ITP, if anyone wants to play with the code before then, I'll make an upload to experimental if you just ask (or you can just build estron from Debian SVN).

An issue that causes ongoing discussion is what is the purpose of a Planet installation such as Planet Debian [1]. The discussion usually seems to take the less effective form of what is “appropriate” content for the Planet or what is considered to be “abuse” of the Planet. Of course it’s impossible to get anything other than a rough idea of what is appropriate is the purpose is not defined, and abuse can only be measured on the most basic technical criteria. My personal use of Planet Debian and Planet Linux Australia [2] is to learn technical things related to Linux (how to use new programs, tricks and techniques, etc), to learn news related to Linux, and to read personal news about friends and colleagues. I think that most people have some desire to read posts of a similar nature (I have received a complaint that my blog has too many technical posts and not enough personal posts), but some people want to have a Planet with only technical articles. In a quick search of some planets the nearest I found to a stated purpose of a Planet installation was from the Wiki to document Planet Ubuntu [3] which says ‘Subscribed feeds ought to be at least occasionally relevant to Ubuntu, although the only hard and fast rule is “don’t annoy people”‘. Planet Perl [4] has an interesting approach, they claim to filter on Perl related keywords, I initially interpreted this to mean that if you are on their list of blogs and you write a post which seems to refer to Perl then it will appear - but a quick browse of the Planet shows some posts which don’t appear to match any Perl keywords. Gentoo has implemented a reasonable system, they have a Universe [5] configuration which has all blog posts by all Gentoo bloggers as well as a Planet installation which only has Gentoo related posts. It seems to me that the a reasonable purpose for Planet Debian would be to have blog feeds which are occasionally specific to Debian and often relevant to Debian. Personal blog posts would be encouraged (but not required). Posts which are incomprehensible or have nothing to say (EG posts which link to another post for the sole purpose of agreeing or disagreeing) would be strongly discouraged and it would be encouraged to make links-posts rare. Having two installations of the Planet software, one for posts which are specific to Debian (or maybe to Debian or Linux) and one for all posts by people who are involved with Debian would be the best option. Then people who only want to read the technical posts can do so, but other people can read the full list. Most blog servers support feeds based on tag or category (my blog already provides a feed of Debian-specific posts). If we were going to have a separate Planet installation for only technical posts then I expect that many bloggers would have to create a new tag for such posts (for example my posts related to Debian are in the categories Benchmark, Linux, MTA, Security, Unix-tips, and Xen) and the tag Debian is applied to only a small portion of such posts. But it would be easy to create a new tag for technical posts. Ubuntu is also the only organisation I’ve found to specify conditions upon which blogs might be removed from the feed, they say: We reserve the right to remove any feed that is inaccessible, flooding the page, or otherwise interfering with the operation of the Planet. We also have the right to move clearly offensive content or content that could trigger legal action. That is reasonable, although it would be good to have a definition for “flooding the page” (I suggest “having an average of more than two posts per day appear over the period of a week or having posts reappear due to changing timestamps”). Also the “could trigger legal action” part is a minor concern - product reviews are often really useful content on a Planet… Some time ago my blog was removed from Planet Fedora for some reason. I was disappointed that the person who made that change didn’t have the courtesy to inform me of the reason for their action and by the fact that there is no apparent way of contacting the person who runs the Planet to ask them about it. Needless to say this did not encourage me to write further posts about Fedora. If a blog has to be removed from a feed due to technical reasons then the correct thing to do is to inform the blogger of why it’s removed and what needs to be fixed before it can be added again. If a blog is not meeting the content criteria then I expect that in most cases the blogger could be convinced to write more content that matches the criteria and tag it appropriately. Having criteria for some aspects of blog quality and encouraging the bloggers to meet the criteria can only improve the overall quality. Currently there is a Planet installation on debian.net being recommended which is based on Planet Debian, but with some blogs removed (with no information available publicly or on debian-private as to what the criteria are for removing the blogs in question). It seems to me that if it’s worth using Debian resources to duplicate the Planet Debian then it should be done in a way that benefits readers (EG by going to the Planet vs Universe model that Ubuntu follows), and that if blogs are going to be removed from the feed then there should be criteria for the removal so that anyone who wants their blog to be syndicated can make whatever changes might be necessary.

• [1] http://planet.debian.org/


• [2] http://planet.linux.org.au/


• [3] https://wiki.ubuntu.com/PlanetUbuntu


• [4] http://planet.perl.org/


• [5] http://planet.gentoo.org/universe/

Share This

There is some discussion again about what should be on topic for Planet Debian, whether it should be used for Debian-related announcements and what the archival policy should be. I believe that this discussion is rooted in two circulating views of what Planet Debian should be:

1. A forum for DD's to post Debian-related thoughts and ideas, to be used for those cases where they think a mailing list post may be less appropriate;
2. A way to collect stories about what DD's do and think in any context, the human interest angle: get to know your Debian peers more than just in technical matters.

Although I always regarded Planet Debian to be the latter and I appreciate reading posts telling me about someone's job or other interests, either one isn't an invalid approach per se. They do however prompt different choices about listing policy (Debian-only feeds vs. everything goes), how much effort it is to keep up with them and perhaps archival. The best way to match the expectations of those two groups would be to create two "planets", one for each group. Create an aggregator where any DD can add any of their feeds, and another one with a strict listing policy: only feeds that carry posts actually related to Debian development matters (probably a subset of the first). Then only the question remains which one will get to carry the Planet Debian name...

And fisl9.0 is over. This was a great one not only because of its size, but there were so many things at stake that I am positively surprised such a few went wrong. We ve got a lot to think until next one To begin with, there s a major difference between this inter-fisl time: we already know where next s going to be and how much it ll cost us. The event-center cost, as you can imagine, is the most expensive part of our budget, and knowing that in advance, I believe, will play an important role in our planning. Also, we got more time to plan for the next one: it ll be in June, not April, as usual. Moving back to PUCRS (from FIERGS) as fisl s event-center now I can say was scaring me to death. PUCRS is smaller and we were foreseeing a huge event. Guess what! The event was bigger than first imagined, and PUCRS held it without major drawbacks. Sure, lectures were crowded but they were already crowded at FIERGS anyway The expo had more people than FIERGS, but I am sure our sponsors did not think that was a problem ;-) Of course, not everything went OK I think we had two important problems to solve for next fisl: our network must be born already correctly configured for the streaming, and our wireless infrastructure must be stronger. The first one I already wrote about and I think it had to to with the inexperience of the network people this year: apparently they ve put everything under a crappy load-balancing and while this might work for web-surfing or sending small amounts of data, it just hurts anything that should be continuously transfered, like real-time videos. Here is a piece of advice: network planning involves the right amount of everything (the right amount of cables, the right amount of bandwidth, the right amount of uplinks), including the right amount of configuration! I think our network problems were more a case of overconfiguration than one of lack of skills. The problem with the wi-fi is deeper. Maybe I don t completely understand the technology (and people handling it were not very helpful). How do you manage an event like fisl in the wireless front? PUCRS have provided us with enough wi-fi to hold 1500 concurrent connections (so they say), and have reported we never had more than 400 concurrent connections and yet, as many people have reported, to connect our laptops was a hassle. I don t have a laptop, but I ve seem a lot of my friends trying to connect with no luck. During the second day, PUCRS wi-fi technicians told us that the problem was the Access-Points people brought to fisl (according to them there were more than 30) that were, somehow, messing with the channels they were using. So we reserved some channels to PUCRS and asked people to use other ones. I tend to believe that the majority of the people listened to our appeal and reconfigured their Access-Points but no improvement were reported. So, either PUCRS cannot hold more than 400 concurrent connections in their wi-fi system, or there s some other problem we ve not identified. What is the right thing to do? To forbid people to bring their own Access-Points? No way I am going to see the day fisl organizing committee will disallow people to carry their own communication devices!! There must be a better solution I think I am going to study wi-fi at least not to be easily fooled around by this messing the channels crap (please, comment to this article if you have any ideas). Finally, people are dreaming of a 10-thousand people fisl next year. I think it s not more than a dream but hey! When we made the first fisl, there were only 300 people it has been a 9-year long dream Maybe that 10-thousand one will come true, as the previous ones did. I will just add one more problem to our list: the first day long lines to get people s badges must be addressed in a creative way Thanks to all that came to fisl. See you next year!

I m a person who isn t satisfied with a lot of things. This both affects me and helps me on several circumstances in life, such it is. The latter also affects my way to deal with mail, mail serving and MUAs. For years, I was a strong Novell Evolution user, mainly because it was quite easy to use, it was pretty and it used to understand the needs that people like me, involved in a lot of things (some of the worthwhile, some of them shitty), required. But in the last couple of years, it began to bloat, to handle connections Bayesian filters and SpamAssassin in a way that was utterly broken and decomposed. I took a break years ago, and tried Mutt, as many free software folks and Debian developers use them on a daily basis to deal with even more incoming mail. I actually liked it, but I was just unable to deal with spam too. My local config was probably broken, fixing it was an obscure fart of Benedict XVI and hidden folders for mailing lists were just a way to forget that I actually was subscribed to mailing lists and focused only on the incoming mail on the inbox. I then tried KMail, since I started usign KDE. It was good enough for it was sometimes slow when trying to load or search on about 100 000 mails and it just didn t fulfill me. I also tried Thunderbird which only made me hate its very closed format to display its ugly UI. Besides, a lot of things on it were getting my angry, like the message filters, etc. So I just didn t give a damn and moved my whole personal mail accounts to Google Apps, giving an opportunity to a totally different approach on mail handling. So I started using the Web interface of GMail. At first I was shocked watching me dealing with a Webmail but after a while I started getting used to it and liking it. Its way to put all conversations threaded on a central inbox was sweet (i was able to filter, tag and take out of inbox too). So I liked it. Some things have never liked me whatsoever: It will always use your default mail address to reply to all messages, even if they are delivered to another recipient, which I consider retarded; its way to let users to top-post, etc, (you should also see how debian-private is seen on GMail and how the google sponsored links propose products based on all its threads xD). The good thing here also was that while not being a total purist, I loved that most spam has automatically handled for me, oh thank Lord I m a lazy bastard. Then I found Sup, which I think is like GMail but on mutt. It is written in Ruby and distributed as a gem (I d prefer it to be in C/C++, but I ll always give the benefit of doubt). Its main feature? A console mail client featuring GMail s features, such as, one inbox, one big archive and labels all over the place, which is exactly what I was (probably) looking for. As the time of writing,Sup can only connect to IMAPs remote servers or read a number of local file formats. So, I undusted fetchmail and set it up. Since all my mail accounts now are forwarded to the main GMail account, I only need to handle one fetchmail config to get messages with POP (and some procmail recipes salting touch). Here comes the sweetest thing from all this setup, by enabling GMail s POP support, you can also specify if you want it to delete the GMail copy or store it. Since I ve used 2% of all my storage, the best thing to do right now is to store and archive, which means that while i download all my email everyday and several times a day, all downloaded copies are also being stored on GMail, so in case I don t have access to my machine, I can still find messages on the web interface. GMail also works nicely when you are sending an email from your remote mail client and using GMail s SMTP, then also the mail you are sending gets stored on your GMail web interface, which is totally cool. So I think I m mildly content now with what I have. This also leads me to another awesome feature for me: Spam gets processed by GMail before I fetch it, so most of my downloaded POP mail is ham. In case I want to see some spam, the web interface will have it as usual for 30 days before being deleted. I like to improve my time for productivity, to get more things done in less time, I do like learning about it, and the proof of concept for GMail handling being used by Sup and the free facilities that Google offers to dudes like me is just a great of avoiding procrastination. It s a hell nice bag of features for me, and probably for you, why not try it?

I just came home from Berlin where we founded the OLPC Germany association ("OLPC Deutschland" e.V. in the last two days, which mostly ment deciding on our final constitution.

The meeting was quite relaxed, it contained just of two five hour sessions, followed by a very good and quite cheap dinner in a vietnamese restaurant with free wifi.

During the 3h trip back we already received two applications for new members :-) I happen to know this, because somehow I ended up on the board of the new association...

And so it was mostly a Debian free weekend, though not really: I slept at Henning Glawes place, a fellow DD and FAI developer and enjoyed his hospitality a lot, even if it was really short. Plus, I discussed with Matthias Schmitz the future of the munin package in Debian. Quick summary: get 1.2.6 out and into Lenny and expose the 1.3.x branch to more testing via experimental, so that hopefully 1.4 will be ready in time for Lenny+1. SSL support are the two words I'll mention now and here, why 1.4 is nifty, but there are more reasons. Check it out ;-)

And now I'll go afk to relax, saturday morning was also the first day I woke up completly free from fever...

I've updated the IMAP utility that I mentioned previously, which has now been given the name sift. It will accept, and process, a much simpler configuration file format keeping state as it goes. Here's my updated sample file:

username: blah.bah
password: pas.word
#
#  Comments are fine.
#
folder:livejournal status:new subject:temp mark:read exec:~/bin/notify
folder:foo status:new mark:read
folder:bar status:old exec:/usr/local/bin/record delete

Each line consists of a set of tokens, split by whitespace, which is "executed" in order. So the first line selects the folder "livejournal", finds messages which are "new", then each message containing "temp" in the subject is marked as read, and the program "notify" is executed once for each match. Essentially we keep a list of messages as "current" as we process each line, that list of messages is then refined as we move through the line. (When a folder is opened all messages are selected by default.) As a simple example to delete all the messages contained in a folder we'd use this:

folder:foo delete

To refine that to only delete messages from "fred" we'd say:

folder:foo from:fred delete

(If there were no matches the "delete" action wouldn't occur.) Consider each line of input a collection of filters each operating on the previous result. Simple to understand, simple to extend with more operations, and simple for me to code! TODO: Add a "move:xxx" to move a message to folder "xxx", and a bit more polish, then release. ObQuote: Tron.

Recently a Debian Developer resigned from a position of responsibility in the project by writing a blog post. I won’t name the DD or the position he resigned as I think that there are general issues which need discussion and specific examples will get in the way (everyone who is seriously involved will know who it is anyway - for those who don’t know, it’s not really exciting). Also I think that the issue of the scope of a Planet installation is of wider importance than the Debian project, so it would be of benefit for outsiders who stumble upon this to see a discussion of general issues rather than some disagreements within the Debian project. There has been some mild criticism of the DD in question for announcing his resignation via a blog post. I don’t think that this is appropriate. In the absence of evidence to the contrary I’ll assume that the DD in question announced his resignation to the relevant people (probably the team he worked with and the Debian Project Leader) via private email which was GPG signed (if he indeed intended to formally resign). The resignation of one DD from one of the many positions of authority and responsibility in the project is not going to have a great affect on the work of most DDs. Therefore I don’t think that it was necessarily a requirement to post to the debian-private mailing list (the main list for communication between all developers regarding issues within the project) about this. It was however an issue that was bound to get discussed on debian-private (given that the circumstances of the resignation might be considered to be controversial) so it seems to me that sending an email of the form “here is a blog post I’ve written about my resignation” would have saved some pointless discussion (allowing us to skip the “why didn’t you send email” and get right on to the main discussion). A resignation letter from a public position of responsibility is a significant document. Having such documents stored on publicly accessible places is good for the community. Having a record of all such documents that you have written stored on your own server for reference (by yourself and by other people you work with) is a good thing. Therefore it seems to me that a blog is an ideal place for a resignation letter. It used to be regarded that there was a certain formality in such things, and that a letter of resignation was required to be delivered in the most direct way possible (by hand if convenient) to the person who receives it. If such conventions were followed then a blog post would occur after the receipt of the letter of resignation had been confirmed (possibly in this case a confirmation email from the DPL). But in recent times things have become less formal and the free software community is particularly informal. So it seems quite appropriate to me to have the blog post come first and the email notification merely contain the URL. Now a letter of resignation is expected to contain certain specific details. It should say specifically what duties are being resigned (particularly important when a person performs many tasks), it should have a date from which it will take effect, and it might be appropriate to mention issues related to the hand-over of tasks (whether the person resigning is willing to work with their replacements). The “resignation” (if we should call it that) in question did not contain any of the specific details that I would expect to see in a formal resignation. This indicates to me that it could be interpreted as not being a formal and official resignation, but instead being a post (possibly written in haste while angry) about a situation which may not end up being an official resignation. Until we get some more information we won’t know for sure either way. This demonstrates one problem with blogs, people usually have a mixture of serious documents and trivial things on the one blog. It can be difficult to determine how seriously to take blog posts. I’m not sure that there can be a good solution to this. At the moment some people are suggesting that every DD should read Planet Debian [1]. I disagree with that. If there is an issue which is significant and affects the entire project then it should be announced on one of the mailing lists such as debian-private, debian-announce, or debian-devel-announce (and will be announced on one of them eventually even if not by the person closest to the events). Forcing every DD to read a lot of blog posts is not in the best interests of the project. Now we could create a separate Planet installation for such things, there is already Debian Times [2] and Debian Administration [3] which serve as a proof of concept. If there was a Planet installation for important stuff related to Debian which had it’s content syndicated in various ways (including an email gateway - Feedburner.com provides a quite useful one) then requesting that everyone read it’s content in some way (either by web browsing, an RSS feed reader, syndication in another Planet, email, or something else) would not be unreasonable. The volume of posts on such a Planet would be quite small (similar to the current announcement mailing lists) so if received by email it wouldn’t fill anyone’s mailbox and if people visited the web site they would only need to do so every second month if that suited them. The issue of what types of posts are suitable for Planet Debian is probably going to get raised again soon as a result of this.

• [1] http://planet.debian.org/


• [2] http://times.debian.net/


• [3] http://www.debian-administration.org/

Share This