As Linux-VServer is currently asleep, I thought about what may be possible only with the functionality the upstream Linux kernel provides and a helper module.

As I wrote some time ago, I did consider switching to a new blog software, the OpenSource Edition of MovableType. I’ve actually done that some 6 weeks ago and must say - it is one browser based application I am actually happy with for myself. (Good god, I must be really ill). I know that about all the things that changed in my blog, compared to my old blosxom based version, are actually doable with blosxom too. For some reasons I just never got around to doing it. Anyways, some things I still remember that changed:

• I got comments and trackbacks support. Not that anyone except spammers and myself did use trackbacks yet, but comments got used, especially in the last few ftpmaster and delegation related posts. Also, the Anti-Spam plugins you get with MT version 4.1 are pretty good. I haven’t had a spam trackback show up yet. They all directly go into the Spam area, which I sometimes just delete. Same for the comments. As I’ve set it up that all comments need approval (unless someone already made a non-spam comment so I set them “Trusted Commenter”) and also have to pass the spamfilter I haven’t had a problem with spam comments. And while I offer 7 different ways of authenticating yourself when you want to post a comment here, including the famous anonymous way with a captcha - only one spam comment got in yet.
• Comments and Trackbacks are automagically closed by a Plugin when the entry reaches an age of 30 days.
• I now can do “Scheduled” posts. Within blosxom I would need a cronjob that copies the file with the blog entry into the right dir, in MT I just select the posting time in the creation window for an entry.
• The category system, especially with having one entry appear in multiple categories, seems to be way simpler. Including the ability to easily generate per-category rss feeds.
• MT generates (in default setup) static pages. Only the comment part is not static (hehe, of course not).
• Editing no longer resets the published time, which blosxom based on file timestamps. I can edit as much as I want, the entries keep their time. Unless I manually change that time.
• MT also seems to be able to handle your whole homepage. And file storage. And cms like (with plugins, afaik). And whatnot. And is “multi-author” capable. And multi-blog.

What it not has is the ability to use a version control system for your posts. Of course not, its a web based editor which stores its data in a database. Oh well, lets stop here, basically - I just like it. :) Comments: 0

I haven’t had my virtual victory lap yet, so here it is:

I've been using GMail ever since they decided to allow users to download their mail using POP. I was happy reading my email as usual in mutt. The only problem was that I had to log onto the website once in a while to clear out my spam folder and fish out the false positives.

However, as the amount of spam I receive daily started growing exponentially (in part thanks to my involvement in Debian), I became more and more dissatisfied with this solution. I had to login several times a day just to keep the levels of spam down to a manageable level. I tried emailing the GMail support team a few times without success.

The solution came just as I was looking at switching to a different email provider: IMAP access.

Using fetchmail, I can now download my received and sent mail using POP and then download (and purge) the contents of my spam folder. Here are the relevant lines of my ~/.fetchmailrc:

poll pop.gmail.com protocol pop3 user "fmarier@gmail.com" is "francois" password "" fetchall ssl
poll imap.gmail.com protocol imap user "fmarier@gmail.com" is "francois" password "" folder "[Gmail]/Spam" fetchall ssl

I can then run all of my mail through my own SpamAssassin filter (to which I added these excellent custom rules) and sort my mail in one of three folders:

• definitely spam (conveniently located in /dev/null) for a score greater than 12
• probably spam (I need to check those manually once in a while)
• not spam for messages with a score less than 5

This is done using procmail with the following bit in my ~/.procmailrc:

# Use spamassassin to check for spam
# (only check messages 400kB so that it doesn't choke) :0fw:/etc/mail/spamc.lock
* 409600
/usr/bin/spamc

# Throw away messages with a score of > 12.0
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

:0:
* ^X-Spam-Status: Yes
/home/francois/mail/spam

Since my DAM rejection earlier this year I’ve been trying to cut down on Debian work. Unsurprisingly (and perhaps surprisingly to some) I fealt a bit emotionally drained and demotivated from defending myself and working with debian security. Lately I have been working with new maintainer Andrea De Iacovo and I am very pleased with his work on Wordpress. Wordpress takes most of my time, like the beautiful day of Saturday yesterday. :) Unfortunately Andrea has had problems finding a sponsor, though a Wordpress security release expedited matters and got Nico Golde’s upload powers into action. :) So if you’re a DD and you use Wordpress, please help out Andrea. Before I get unsubscribed from Debian Planet, I thought I should pimp my:

• Debian tips and tricks site – the current 400-odd tips are in the public domain so please rip them, update them or add some!
• The fantastic Web kiosk distribution Webconverger based on Debian Live, which also has a blog

Both based on ikiwiki. ;) Anyway, I am still around of course. Met some great people in the Debian community and sadly some pretty pedantic unfriendly ones too. Final suggestion for DDs: Revoke your GPG keys more often and go to less key signing parties. :P

Last night, my flatmate asked the question of whether it is possible to do anything in a selfless way, or whether everything one does can be traced back to one s own interests. I am not fit for these kinds of philosophical arguments anymore, so we pursued another topic instead. Today I am sitting on a Swiss flight and am being bombarded by commercials on the stationary television screens they use for safety instructions and the onboard entertainment. Swisscom purchased advertising space, and there they proudly let us know, in German, English, and French that 1 million kids in Switzerland jump for joy as Swisscom brings free Internet access to their schools. Simply so. (sic). When I read this, I first though: why the heck are Swiss schools still in need of Internet connections? Why do we tolerate an economy or situation in which the Internet isn t ubiquitous yet? And then, my mind suddenly made the connection to last night s discussion on selflessness: even though Swisscom is trying to communicate that they re being selflessly good by providing access to the school s, they obviously aren t, or they wouldn t be using the factoid for advertising. The curious aspect is that I wouldn t normally have absorbed their message or linked it to last night s discussion. The reason that I did is because of the gross errors in their English translation. The German einfach so , which I think they translated wrongly, suggests that they did something without any particular reason. I am not a native English speaker, but simply so doesn t exist, and it (thus) doesn t have that meaning. Dear Swisscom, and all other companies who think that English is hip, or who actually want to reach out beyond the borders of four-language-Switzerland: consider employing someone who can speak the language to help with your marketing. Even if you want to let the world think that what you do is without commerical interests. NP: The Flower Kings: Unfold the Future Update: initially, I criticised Swisscom for using jumping for joy , which makes no sense to me. Apparently, however, it s an idiom. I should have checked, especially since I am criticising the use of a language non-native to me. Thanks to the various people who wrote in for kindly pointing out my mistake.

In this post, Steven Hanley wonders how to keep /var/cache/apt/archives empty on a machine that has a full mirror of debian on it. That’s actually the wrong question. The right question is ‘Why is /var/cache/apt/archives even relevant on a machine with a full mirror of debian?’ /etc/apt/sources.list has always supported file:/ URLs. for example, sources.list on my local debian mirror looks like this:

deb file:/home/ftp/debian unstable main contrib non-free
deb file:/home/ftp/debian-multimedia/ unstable main

With a file URL, apt-get doesn’t need to download any packages, and thus doesn’t need to cache anything in /var/cache/apt/archives. No need to keep it empty, it just is empty. In a related post, Andrew Pollock suggests adding DPkg::Post-Invoke “apt-get clean”; ; to /etc/apt/apt.conf. That would be fine if you ONLY ever ran “apt-get update ; apt-get dist-upgrade”. It’s not fine if you run “apt-get -d” to download packages first, then install a few packages with “apt-get install package”, and then run “apt-get dist-upgrade”. If you try that, then the DPKG::Post-Invoke rule will clean out /var/cache/apt/archives when you install the individual package(s). When you then run the dist-upgrade, apt-get will have to download all the packages again. Better just to get into the habit of running apt-get clean or autoclean occasionally when you want to reclaim some disk space. Syndicated from Craig Sanders' Errata: Miscellaneous Thoughts Keeping apt archives empty…or not.

Following my first ftpmaster blog post, which got some nice replies, lets have the next, as I didn’t stop working on stuff. Not as much as I hoped, but well, something. So, what was done since then?

• Merged a little patch from Christoph Berg fixing usage of a function - which doesn’t exist in global namespace, so it needs the full name.
• Merged another patch from Christoph - now we write the content of the Changed-By field from .changes files into projectb. To cite him for the reason: This will allow to identify NMUs and sponsored uploads more precisely in tools querying projectb. Broke dinstall with this and as a little side-effect also the merkel copy of the projectb database. Ups. Well, fixed it immediately again. :) There is some old data available, which I could import into projectb, so it would have data for all packages. But there is some weirdness with the dataset I got from Christoph and am waiting for him to provide a solution. Anyway, all new uploads already store this data, so it is only old data missing, currently.
• Merged a small patch from Thomas Viehmann into our archive software which enables it to send a copy of all mails to the person sponsoring the upload. This is in affect for all future uploads, not for any package which already hit the queues (like those in NEW right now). We do
  • only sent the extra copy if it is a sourceful upload, to not spam buildd admins,
  • only sent the mails to sponsors who did not disable their @debian.org address.
  For those interested, the process works similar to:
  • We look if the Debian login attached to the key signing the upload has an active @debian.org address.
  • If that is the case we look for all uids on that key that look like an email address and compare them with the Maintainer: and Changed-By: field in the .changes file.
  • If there is no match, ie. none of the “emails” of the key uids is in those fields, the @debian.org mail is added to the set of valid receivers.
• Changed split-done to only move files older than 30 days and let it run by our weekly cronjob. Also run it once, which moved 120079 files into their $YEAR/$MONTH subdirectories. (split-done seperates the subdir where we store every .changes of uploads accepted. That quickly grows fast, and we all know how bad filesystems perform with such a number of files. The above 120079 files are from November/Dezember 2007 til now, so imagine how many we have in total, as we have them back to 2002).
• Merged a patch I wrote 7 days ago that does a little sanity checking in the Provides field. Do not try to version your provide, that is forbidden and actually breaks software. (See this bug about it.)
• Merged a patch, submitted by Marc Brockschmidt some long time ago, that lets cruft-report also display NBS for experimental. Changed the cron script to use that extra feature.

---

And as in my last blog post, lets add some items to the todo list:

• Enable dak to read a Built-By field from the .changes file. Thats the sanest solution to sponsored uploads. And also better for buildds, they then should no longer overwrite the Maintainer field with the -m parameter when building packages. Exact semantics to be defined, but dak probably would go something similar to
  • Built-By same as Changed-By or Maintainer?” - do not send mail there.
  • Built-By differs from Changed-By or Maintainer and its sourceful? Send mail to it too.
  • Built-By differs from Changed-By or Maintainer and binary-only? Only send mail there.
• Track the Uploaders: field in projectb. That would help the BTS to offer another display.

Having written all this - today (AKA Saturday, when writing this) won’t see code merges by me. I think most of my ftpmaster related work today will be fun with the NEW queue. For some unknown reason people keep uploading packages. Tsss. Comments: 3

A few news from the campaign of NMU's targeted at bringing po-debconf translation ratio as high as possible for as many languages as possible (and also improve packaging quality quite significantly on many loosely maintained packages).

• Galician translation are going up quickly. Each NMU features updates by Jacobo Tarrio and Galician is now ranked 10th in the translation ratio list. They could even hit the Spanish (Castillian) translation ratio and become the most translated language from Spain..:-)
• Finnish follows the same way. Starting from quite low, Esko Araj rvi bringed it to 13th rank and now above 50%
• Russian is also going up quite fast and could at least reach 70 or even 80%
• Portuguese (non Brazilian) hit the 90% mark and heads up to 100%
• German is very likely to be bringed to 100%. Crossed 97% today.
• French will be bringed to 100%, as it was for Etch. Close to 99% now.

Maintainers are incredibly cooperative (at least those who are active..:-)). l10n NMUs are always welcomed. Some prefer uploading themselves which is of course perfectly OK. I will now also focus my efforts to minimize uncoordinated changes to debconf templates. Those are generally motivated by the will to follow writing style guidelines, which is perfectly OK. I however still suggest maintainers to send call for translation updates *before* uploading packages with modified templates. Will probably soon post that suggestion to -release.

Note that by "Enable Touchpad" it also means "Make my touchpad mouse buttons work". For machines that are only equipped with a touchpad (and, indeed, some that are equipped with a trackpoint as well - it depends on how it's wired up), the only option is to figure out that the space bar or enter will save you.

(Ubuntu-specific change, introduced in 8.04)

Some days ago I complained about snmpd having a memory leak in Debian Etch, which seems to be related to the Etch version, as someone commented there. Anyway, todays complaint is against spamassassins spamd and its memory usage:

top - 18:36:15 up 30 days, 5:17, 12 users, load average: 9.60, 4.95, 2.38
Tasks: 170 total, 2 running, 168 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.6%us, 1.4%sy, 0.2%ni, 31.7%id, 66.0%wa, 0.0%hi, 0.0%si, 0.1%st
Mem: 1048576k total, 1041264k used, 7312k free, 0k buffers
Swap: 1048568k total, 695652k used, 352916k free, 35568k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31694 nobody 18 0 565m 360m 2396 D 1 35.2 0:08.45 spamd
23003 root 16 0 565m 344m 2456 D 0 33.6 40:54.15 spamd
27052 nobody 16 0 94216 40m 2456 D 0 3.9 0:29.96 spamd
9241 clamav 15 0 224m 39m 740 S 0 3.8 3:19.17 clamd
31711 nobody 15 0 89856 36m 2464 S 0 3.6 0:00.37 spamd
31750 nobody 16 0 89244 36m 2436 D 1 3.5 0:00.24 spamd
30751 root 15 0 87884 17m 2176 S 0 1.7 0:09.42 spamd

Some spamd processes are using a incredible amount of RAM, sometimes even eating up all memory including swap. I know that a bigger commercial site is suffering from the same problem as it was mentioned in their job interview with me lately.

Spamassassin is invoked by exim4 on my system during SMTP data checks with a condition like:

condition = $ if $message_size 128k 1 0

So, this should ensure that only mails smaller than 128 kB are passed to spamd by exim. So, either that condition doesn't work (it should as it's basically the same as in the exim4 docs) or spamd is a memory hog even with small messages.
I wonder if there's any method to stop spamassassin from using that much RAM?

It has been some time since I ve blogged about Subversion and how I was finding it useful. I ve been using subversion and svk since about that time and I love it. Svk is really great and although it is more an off-line version control than a distributed one, it goes a long way for a former cvs user like myself. Lately, I ve been considering git (isn t everyone?). It was not until I moved to my own hosting (thus having to maintain two subversion trees: the new one and my company s old one) that the whole having a central repository started bothering me. Merging became complex, since now I have two central repositories, and while svk makes it a lot simpler (I just keep a mirror of the two repositories and use svk to merge between them), I began to realize that there should be a better way I ve watched (again) Linus git lecture at Google Tech Talks and decided I was going to try it. First thing that called my attention was how easy it is to share a repository: just copy the .git directory somewhere public (an http server, for instance), and there you have it. This is much easier than configuring modules for apache, or configuring svnserve (and I ve done that a lot in the past 3 years!). For the subversion-only user (one that has never used svk), the carry-all-the-repository-with-you thing may sound strange, but with svk, I was used to mirror the repository, so that s not an important change to me. I could not compare space utilization (and git is advertised for being more space-efficient) yet, but so far the git repositories seems to be a little smaller. I already found it easy to branch using svk (in fact, I used to do that a lot), but git branching is really a plus! You can switch back and forth inside the same working copy (actually I don t think it s correct to call that a working copy) and merging is rocket-fast! Maybe if svk could easily merge between two distinct users without requiring a subversion repository (think about the defunct svl), I would not have been trying git, but One thing that is really missing is the partial checkout. Actually I liked very much that svn/svk feature , and the clean and natural way which they treat directories and files. I understand git is designed with other priorities in mind, but, right now, that feels like missing to me. Maybe it s just a svn/svk habit. All in all, I found git very interesting I am not ready to switch from svn/svk yet, but I ll try git in small new projects and see if I can get used to it.

Last week, eight pounds of Perl books arrived at my doorstep, courtesy of deciding to work for Best Practical this upcoming summer. They’re cool people, very free software friendly, and conveniently located in Davis Square. They are also the makers of RT among other things, which Debian uses for a variety of purposes. It should be a good time. (No, I probably won’t actually be hacking on RT, but exactly what I’ll be working on is as yet undetermined.) Speaking of the summer, I have a vague plan to make a West-coast visit for a week or so at some point. I’ll be hitting at least Seattle and San Francisco; if you’re around either of these areas or possibly even somewhere in between and would like to hang out, drop me a line in comments or via email.

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

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!