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!

I'm happy to point to the announcement that Wikitravel Press now has a guide to Paris. Paris has long been a targeted city for Wikitravel Press, and I'm really happy we were able to get this book out. Bonus: the Wikitravel Guide to Paris includes maps from OpenStreetMap, the Open Content geo database and mapping system. We've got some new software to overlay Wikitravel listings onto the maps, and it's working really well. Thanks to OSM, editor Mark Jaroski, and managing editor Jani Patokallio for getting this great book out... just in time for Paris spring! tags: wikitravel wikitravelpress paris guidebook opencontent openstreetmap

Podcasts I asked a couple of days ago (Journal/30 Germinal CCXVI) about podcasts on the subject of Open Source and Open Content. I wanted to summarize a few that came in through comments on my blog:

• The iCommons Podcast, which (like many podcasts) seems to be running a little slow -- no updates in about a year. Still, an interesting project to be watching. (thanks Brianna)
• Wikipedia Weekly, the really great show by Andrew Lih and Liam Wyatt. I should have thought of WW before -- I was interviewed for the show last year! (thanks Padraic)
• Also worth noting is Not the Wikipedia Weekly, which is, uh, not the Wikipedia Weekly. I got this one from an episode of WW!
• LUG Radio, which I found from another podcast, LQ Radio.

This has turned into a pretty decent list, but I'd love to see some more diverse discussion of Open Content and Open Source in general. Please, feel free to send more tips. tags: podcast linux opensource opencontent

Vinismo For some reason Vinismo went over some tipping point with StumbleUpon this weekend, and we had a real flood of users from that bookmarking site. I can't say why that happens; I find SU to be a totally opaque Web site and service. In other news, Stevey likes our business cards. Me too! I think they look great. M-C Doyon, the Montreal graphic designer who laid out our Web site, also did our paper branding, and I think she did a great job. tags: vinismo stevey marieclaudedoyon cards

Yay Firefox 3.0 I don't know when it happened, but Firefox 3.0 beta does non-ASCII characters in the address bar correctly. So, if you're reading this entry on my site with FF3, you'll see the in "Flor al" rather than the URL-encoded "Flor%c3%a9al". I also like seeing Japanese Wikipedia pages in the address bar showing up correctly. Nice job, FF3 team. tags: firefox firefox3 utf8 url

Planet software should preserve categories So, apparently there's once again rising problems with content drift on Planet Debian. Personally, I think this is a problem with a technical solution. All three main flavours of RSS support post categorization. Many, many kinds of feed software provide categories (see, for example, this feed). If the Planet software would preserve these categories and pass them through to the output RSS feeds, then people who really only want to read about Debian could filter the output feeds for category "debian". People who wanted to know about other parts of their fellow Debianistas' lives would just leave the feeds unfiltered. I'm not sure if the Planet software doesn't support categories in output at all, or if it's just an option that's turned off on Planet Debian. If nobody else wants to take a look, I can look into making this work. It seems like a pretty simple fix. tags: planet planetdebian rss categories

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

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.

It seems everybody is ranting in Planet Debian about what our planet should be about, what content should be acceptable, whether technical-only, Debian-only, everything-goes... Even archiving the posts via a mailing-list interface has been mentioned. Besides, following the planet seems to have become mandatory to people linked to Debian, almost as mandatory as following debian-devel-announce.
I won't bother linking to other posts in this topic, as they are far too many. The whole discussion seems childlike and sterile to me. For different people, Debian means different things - This topic has come up in the planet a couple of times in the past (funny, hah, using posts in mutually-unlinked personal blogs as a way to follow a discussion). And a planet should IMHO cover a specific use case: Providing a place for those of us who think of Debian as a social frame, and value knowing -exactly- the type of information each of us publishes in his/her blog: What's up with Debian-related people's lifes.
Of course, a large fraction of this information should be somehow technical or Debian-related. But I do value having a place to learn about my peers' life accomplishments. To know if they are going through a hard time. To understand the personal interests of them. Maybe to learn I'm not the only DD who enjoys running (although I'm far under Dirk's or Christian's league) or cycling in a big city (although I lack MJ's political involvement and dedication). I actually like trying to find some logic in senseless Steve-like messages, there are some funny bits in his stuff. I like knowing I can share what I feel important about my life in a simple way with my peers, without having them drop over to my site. And yes, of course I do enjoy learning about the ongoing technical work of the bunch, even if it is often in fields I would not wander into at all (i.e. Simon's frustration with writing device drivers for Windows, Michal's advances on Gammu).
So... Please stop over-regulation. Leave the planet as it is. If you don't like it, come up with a way to filter and maybe adjust its content based on user profiles. But don't try to censor it.

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?

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

I’ve noted in the past that Debian has deliberately enshrined in its constitution some rather serious principal-agent problems. By and large this isn’t a bad thing, since there isn’t the consensus within the Debian community to support the “benevolent dictator for life” model of decision-making—if you want that, well that’s what Ubuntu and Daddy Warbucks is for. But it does mean that sometimes the caca hits the fan when a Debian project leader does exercise his powers, as our now-former DPL did earlier this week just before the end of his term of office (by my estimate, just over one hour and 27 minutes before). John Adams would be proud. So we have three related issues in my mind:

• As a matter of general principle, lame-duck DPLs shouldn’t be making appointments. This issue is ameliorated somewhat because DPL delegations—unlike “midnight judges”—can be revoked at any time, but it strikes me that whatever legitimacy a DPL has from the developers evaporates once a new DPL-elect has been designated. I can only speculate why this happened in this case, so I won’t bother.
• Second, while Debian has a very strong tradition of developer sovereignty, with many aspects of the project being self-organized rather than originating with appointments from upon high, it seems to me that certain aspects of core infrastructure can’t be managed in this way.
• Third, the appointment does little to relieve the excessive concentration of power in the core of Debian; if anything, Anthony Towns’ apparent resignation in the wake of Jörg’s appointment worsens the situation. Ensuring there is proper vetting of people with access to important infrastructure is important, but at the same time I find it difficult to believe that there are only a half-dozen or so Debian developers who are trustworthy enough to be system administrators, account managers, or archive maintainers (several of them occupying overlapping positions). That, rather than a lack of technical tools, has been a problem of note within Debian since, oh, the days of my youthful vigor within Debian (which are long since past).

In any event, congratulations to all the new Debian developers—and I’ll avoid pondering for too long why one person’s appointment to an unrelated group would suddenly break the logjam of developer application approvals.

Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

• Windows 2000
  
• Windows 2001
  
• Windows 2001 SP1
  
• Windows 2001 SP2
  
• Windows 2001.1
  
• Windows 2001.1 SP1
  
• Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

Laptop stolen Last thursday I flew from Italy to Manchester as usual, and while walking home from Levenshulme railway station my laptop has been snatched off me by a gang of thieves. I've managed to give the police all the details of the laptop including the serial number. I could also precisely describe to them the dynamics of the incident pointing at places over satellite maps in google maps. And give them the time of the theft with 10 seconds accuracy. And show them pictures of all stolen goods with a few simple internet searches. They were impressed. All sensitive data in the laptop are protected with one or two layers of strong encryption, and I have fresh backups, so the only work that I've lost was the work I did on the train and airplane on my way to the UK. If anyone around Manchester or Stockport happens to see, in a Cash Generator or second hand shop, a suspicious looking white ASUS laptop with a Taiwanese keyboard (US-style keyboard with extra Traditional Chinese and Bopomofo glyphs on it), please quietly walk out of the shop, alert the police and send me an e-mail. The day after the theft I managed to talk with a pub owner in the area, and there I learnt that pubs are networked and alert each other when suspicious people are roaming around. Lesson learned: if I see suspicious people around the street whem I'm walking home with my laptop, it's a good idea to go inside a pub and ask how's the situation. That night, for example, they've been alerting their customers of the danger. I wish the railway station had done the same.

So, I'm really getting into the podcasts lately. I got myself a personal music player (one of these) in winter, and I've been using it to listen to podcasts while I run. Earideas has been a huge help in finding new podcasts to listen to. I've kind of graduated from the best of earideas feed, which covers a wide variety of podcasts, and I'm trying to dig into things that really matter to me. Three things in particular, of course: wine, parenting, and Open Source/Open Content. I've found a good number of podcasts on the first two subjects, but only a few on the last. Right now I listen to:

• the infrequent and misnomered FLOSS weekly, which isn't the same without Chris DiBona.
• LinuxCast, featuring the mellifluous tones of Don Marti
• LQ Radio, from Linux Questions.

So, what else is out there for Free, Libre, Open kinda people? Any podcast suggestions? tags: lazyweb podcast floss flossweekly linuxcast lqradio

They ve came down with a participant number for fisl9.0: 7417. That s it over SEVEN THOUSAND! I was told it s still an estimate, since they haven t merged the databases yet (anyway, that s the official number so far). This fisl is huge! One more picture of the crowd, just for the record: Now everything is fine. TVSL went online with no problems (once the network was fixed) and remained broadcasting the event the whole day long. All was so fine that one can think it s even boring! I spent half the day attending our company booth and the other half trying to help the organizing committee. While walking around, two linux-driven home-made robots called my attention. The first one serves water to the guy in front of it: The other one just walks around: On the Debian side of the trench , I met Jo o Eriberto Mota Filho, Debian Developer wannabe who asked me to sign his key. I ve seem he before, since he s a frequent speaker at fisl and welcome him as a future developer. Meanwhile I was reminded by faw that I still owe him my signature since DebConf4!! I signed so many keys in the KSP we held then, that one or two might have been missed I intend to fix that RSN ;-)

Hi, Julien, I agree that Debian is not dying and it was a bad PR move for Lucas to suggest it is, but what makes you think your response is any better from the PR perspective? I too have represented Debian at trade shows, LUGs etc. and I've had to deal with this topic before. My response is not to berate the holders of misinformation (and while I believe you when you say you were only aiming at Lucas, you used the plural so it would be easy for readers to be misled into thinking you meant multiple people.) but to emphasize that Debian is unique. Noone has conducted a social experiment of this type on this scale before and it is only natural for experiments to occasionally result in explosions and bad smells. Adopting this angle does not make us look bad and steers the questioner away from negative lines of thinking without belittling him. Much better PR don't you think?

Some come, others kind of go.

I warmly welcome the new 19 developers (great female ratio there!) and humbly ask the rest of us to support the new blood carriers. If they made it through this, they are surely worthy of our cause and will probably accomplish a lot more if us, the old farts, make it easier for the ones to come in the future.

Where do I join the Debian elderly club?

Dear Jaldhar, I wrote the post you’re referring to knowing that only one person had been stupid enough to title his post “Is Debian dying?”, so before you go on writing I’m insulting a group of people (at least I’m reading your post this way), please do your research. Lucas’ post is about the worst PR we can imagine. There’s nothing more stupid to do than what he did. That’s the PR equivalent of committing suicide, mostly. It’s seriously hindering the work some of us are doing, publicizing Debian, going to trade shows, etc. It’s not only stupid, it’s hurting people who do this work. What’s worse, the post comes with comments from random nobodies, who have nothing to do with Debian, don’t have the first clue about how the Project works internally, yet they can tell that Debian is dying and grinding to a halt. Not to mention it’s been publicized yet again by some “journalist”. I’ve known Lucas for a long time now. I know where I stand. And I maintain my previous post in full, like it or not. Kthxbye.

*Ahem*... I'm soooo excited! After 884 days, I just became a DD. It was almost two years and a half of much work, learning, patience, struggling to keep the morale up, and more work. In fact, Debian is already taking almost all my free time since months ago, something I don't regret at all. I was able to do most of the things I wanted to do, even without an account, including: DebConf organisation, team-maintaining packages (sorry pkg-perl folks, dc8 didn't leave me much time lately), some QA work, coding tools, etc. But this small feat has a huge symbolic importance to me, now the project as a whole is recognising me as a full member; many people already did individually, but sometimes you need the "official" stuff. So thanks to all the people that helped me during the way (sorry for the omissions!): maxy, for introducing me to Debian, marga for encouraging me to apply to NM —and all the moral support—, des for the help and the sarcasm, damog for being my first AM, even if we had our problems, ana for being my second AM and being so supportive, the Perl-lings for being such a nice bunch of people to work with and to learn from. Thanks also to all the nice people I've met along the way (dudes!), you make Debian a nicer place. Update: There was another paragraph that I butchered after noticing that the actual process in the last 24 hours was different than what I thought. But anyway, my thanks to Sam, Myon and Ganneff for their respective help in this process. Also, I don't want to forget to thank Ganneff for the trust he'd put on me during this time. Tags: Planet Lugfi, Planet Debian, Debian