I mentioned a few weeks ago that initial kernel support for the QNAP TS-119 and TS-219 Turbo NAS got accepted for 2.6.30 but that there were some issues left. Here's an update:

• SATA: Kirkwood uses a different SATA PHY and the Orion settings weren't quite right, leading to the timeouts I saw. As it turns out, Saeed Bishara from Marvell had a patch for this already and it will be in 2.6.30-rc6.
• Flash: writing to flash is now possible thanks to a patch from Peter Horton that has been merged into 2.6.30-rc5.
• Parsing the MAC address: Thomas Reitmayr created a patch to parse the MAC address from flash but the kernel people thought this should be done in userspace. I haven't looked into this yet... maybe the best solution is to document that the MAC address will change.

The SATA and flash fixes are already in our 2.6.29 kernel.

Val ncia is again taken over by football fans, who have come from all over the Basque Country and Catalunya to watch the Copa de Espa a final in Mestalla stadium. The city is literally tinted in red, white, blue and maroon and thousands of supporters (more than 60.000) have flooded the streets. If you can't beat them, join them, so for a change, I'm going to join the crazyness and will go to the Athletic Hiria to watch the game in the middle of the leonera. I can't wait to see how the Basque and Catalan supporters who have tickets for the game will react when the King of Spain enters the VIP area in Mestalla. Apparently, more powerful loudspeakers have been installed in the stadium in an attempt to mitigate what I expect to be the biggest catcall in a Spanish football stadium since we have a King... Gora Bar a, Visca l'Athletic!

1. I will be working for the Tor project in this year s Google Summer of Code. I have started a new blog for GSoC-related updates.
2. I am excited about Diego s accepted GSoC proposal for Debian; debbugs web UI.
3. I m in NM.
4. I will be in London during June and July. Any Debian-people up for a geeknic or something?
5. I m looking forward to meeting the people involved in the London Hackspace project and I hope they find a place soon.

It s been awhile since I posted some Jacob updates. He s 2.5 years old now. So here we go! Here s what I think A recent conversation after Jacob had been misbehaving. John: I think we should have some consequences for that.
Terah: Do you think he should have time out?
Jacob, eavesdropping: I THINK NOT! He managed to evade time out that time because once we got over our shocked silence, we were both laughing too hard. The Post Office Every time Jacob and I drive past a Sonic (a drive-in restaurant), he says, See post office over there. Have cherry limeade! Yes, he was there with Terah to get a cherry limeade once. The post office thing was a mystery to me. Near as we can figure, he had gone to Sonic with Terah right after the post office one day, and got them confused. Then I took him to an actual post office last week. I told him we were going to a post office. I started getting him out of the car. He looked confused (after all, post offices don t look like this, right?) But then he said, This post office. Have cherry limeade inside! I had to tell him it is a different kind of post office, with mailboxes inside. Hmm. I gave him a piece of junk mail to carry to the car, which I think may have been more exciting for him than even a cherry limeade. Terah has tried to explain that a Sonic isn t a post office, but he doesn t believe her. Trains and Chicago We took the train to Chicago for a quick weekend last week. Jacob loved it. He jabbers on and on about going to the train station to get on the night train (we did get on the train at 4AM), eating in the train diner car , and seeing all the conductors on the train. He also loves to talk about the elevators in our hotel, riding on a city bus, and seeing ambulances on the streets. Didn t Notice It We got a new Roomba off Woot the other day. Its box has been sitting in our kitchen for a few days now, since we didn t have time to unbox it yet (already have another Roomba). Finally Terah started unboxing it. Jacob said, Ooo, a SPECIAL Roomba! I didn t notice it there. Terah: What makes it special, Jacob? Jacob: Comes from Walmart. Can t win em all, I guess. Colors Terah read in her What to Expect book about the toddler years that, at Jacob s age, there s a small chance that children can identify one color. Jacob can identify more than a dozen, maybe even two. Navigation This really shocks me. As we re driving down the road, Jacob will correctly point out directions to me: This way to day care! That way to grandma s house! That way to Newton! What really shocked me, though, was when he pointed to an entrance ramp to an Interstate one which we never take with him and correctly told me where it went. And when he pointed down a country road that we have never even talked about, let alone driven on, and told me where it must wind up (in Newton, yep). I have no idea how he managed to figure that out. Scary Memory Last week, Jacob got a balloon. It reminded him of a balloon he got last Halloween six whole months ago. He was at a Halloween event for kids, and they gave him a black balloon. It was filled with helium, and it rose up high enough that it touched a sharp edge of a fire sprinkler and popped. Jacob told us about all of that, right down to it being a black balloon that popped on a sprinkler. They gave him another balloon to replace it orange. Jacob told us, Orange balloon not pop. Six months ago. I think it s time to get him signed up for the debate team Days of the week Jacob doesn t know what day it is, or in what order they come, but he does know that we go to church on Sunday, that he goes to grandma and grandpa s house on Tuesday, and to the clinic and Walmart on Wednesdays.

As expected, the French HADOPI law was voted earlier today by the Assembl e Nationale. As expected, my local representative voted in favour of this law. I had however kept a secret hope that he would abstain for this vote, following to the email I have received from his assistant following to our meeting. Mr Vannson planned to take the floor during the finale discussions. He had sent me for review the text they wrote, which perfectly matched my arguments, and even referred to the law as a Rube Goldberg machine ( Ma conviction est que nous avons mont une usine gaz in the original version). This text also stated that he was netiher convinced nor satisfied by the law.

His speech planned for the final discussions of the law never happened, and was replaced by a single line question to the Minister, during a meeting of the Law Commission.
This question was even technically incorrect as he refers to firewall, whereas I had (with a great help from other members of APRIL) amended this part of the text to refer to usage control software :

M. Fran ois Vannson. Les logiciels pare-feu ne risquent-ils pas, madame la ministre, de nuire aux logiciels libres ?
Mme la ministre. Il n y a aucune menace sur les logiciels libres, qui peuvent tout fait accepter des logiciels de s curisation.

From: http://www.assemblee-nationale.fr/13/rapports/r1626.asp Which could be approximately translated as follows:

M. Fran ois Vannson. Mrs Minister, aren t firewall a threat on Free Software?
Mrs Minister. There is no threat on Free Software who can accept well accept securisation software.

I must hence express my real disappointment.
Now, let s hope this law won t be applicable, following the idea of most of its opponents. I won t write to my local representative, as I think it is totally hopeless. I guess he will get the pingbacks from this blog post, as his own political weblog runs on Free Software!

I finally find time to make another release of Gammu. This time it is really just bug fixing and I will stay in this mode for some time, because I have simply too much things to do in real life. Full list of changes follows:

• Fix checking for MPBR (bug #873).
• Fix reading of calls with wrong timestamp (bug #872).
• Increase timeout for IrDA phonet (bug #867).
• Better detect some weird phone states (bug #866).
• Fix handling of caller group in Python bindings (bug #870).
• Correctly detect empty entries from Motorola.
• Better error reporting from at-charset test.
• smsd-inject now shows ID of injected message.
• Fix decoding of date in Nokia phonebooks (bug #876).
• Fix detection of SMS message memories in AT (bug #875).
• Improve documentation for savefile (bug #893).
• Add stricter check for DBI version (bug #894).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon, SUSE, Fedora and Mandriva users can check experimental repository in OpenSuse Build Service.

Yesterday, as I was driving towards towards Bucharest, just after exiting Ro iori de Vede, somebody driving a white van with a trailer almost ran over us. I had to drive on the opposite lane to avoid the collision.

During the incident I was cold blooded and managed to keep a clear mind, but right after it, I felt my knees softening and had to stop to recover.

So, in the remote case that person will read this post, thanks for at least breaking when I horned.

I received a few comments on my previous post, some of which suggested that I file a bugreport explaining my thoughts. Of course I did consider that; and I do agree that in many cases, filing a bugreport is the right thing to do. However, this is not always the case. There are times when you just know that a bug which expresses your feelings towards a particular thing will just be closed on sight, or at the very least tagged 'wontfix'. Filing a bugreport in such a case is just not helpful, and a waste of both my time and that of the maintainer. As such, I just don't do it. Instead, what I will do is rant. Not because I want to annoy the world, but because it helps me to blow off steam that's what my blog is for. Also, writing out my thoughts on a particular subject will often help me to reconsider things in such a way that I'll be able to better formulate what the real bug really is; and if it doesn't, it's likely that other people will respond and point me towards what I'm misunderstanding if I am so that, again, I might be able to better formulate what the bug really is. If I sound frustrated in a rant, that's because I am. The simple fact that someone changed something in a piece of technology that I'm using with the intent of improving things should not have to mean that I agree that it is, indeed, an improvement. I will not hide my feelings because it might offend someone. I've done that too much in the past. So please, pretty please, with sugar on top, when I'm ranting, do not tell me to file a bug report. That is all.

I tried hard, but it seems impossible to find Python programmers for our start-up. I know, living in Pecs (Hungary) limits the choices, but I also tried in Budapest and I was unable to find anybody with a good knowledge of Python and Zope. For this reason, we finally decided with my business partner to experiment with telecommuting.

We are looking for talented Python programmers to join our team, based in Pecs and Budapest (Hungary) with a satellite office in Turin (Italy). You will be able to work from home, planning your time based on your schedule and goals. You will work on the development of a free (as in speech) CRM and marketing platform built on the Zope Toolkit (aka Zope 3).

About you:

• Willing to work in a young start-up;
• You love finding efficient solutions to challenging problems;
• You have a lot to teach and a lot to learn;
• One of your goals is to learn something new each day;
• You prefer quality over quantity;
• You love to get things done;
• You like working in team and having strong responsibilities.

Requirements:

• Strong background in Python and web application development;
• Excellent knowledge of HTML, CSS, JavaScript (Prototype);
• Experience in database design, performance tuning, SQL;
• Good knowledge of PostgreSQL;
• Deep knowledge of Linux, with a focus on performance monitoring and tuning;
• Unit Testing and Functional Testing shouldn't be alien to you;
• Strong communication / collaboration / problem solving skills;
• Willing to travel for real-life meetings and conferences.;
• A resume in a non-proprietary format.
  

Nice-to-haves:

• Knowledge of the Zope Toolkit (aka Zope 3);
• Contributions to open source projects.

If you are interested, drop me a line at kobold@debian.org.

PyCon3 Italia ended yesterday. It was simply great! great talks, gorgeous speakers and so on.

Sadly, when I left these kind of confs there's always a bad taste in my month... I see so many great people that made it, that are satisfied, brilliant and accomplish great results.

Now I feel like I'm one of many, but I want to be one above many; one of Them. Ok, ok, sounds a little bit presumptuous and we all know I'll never be like them but why not trying? ;)

The same thing happened after PyCon2, and I decided I wanted to do more, to be more.

Since an year passed, I think I've done a bit of my proposal: I started using Python as much as I can, I get involved in some project python-related (to name some: reportbug, bts-link, matplotlib) and I'm about at the half of writing a book on matplotlib (that I was offered to write).

I can be a little satisfied by this, but of course, I want to do more! :)

Once the book will be done, I'll probably still be involved with matplotlib evolution, eventually with more important contributions, but I will also search for new challenges.

It might sound ambitious, but I have a strange feeling that python core "stuff" (being the interpreter, the stdlib or near) could be something I can have a look at ;) It could also come up as a too big project to work on in my spare time, but I'll rebase my plan once I've fight for it and lose, not before.

It's great that in these supposedly straightened times InternetNZ have wasted no time in confirming themselves as key sponsors for LCA in Wellington in 2010. Now if only all of our other sponsors could line up behind them (please) and tell me the extent of their sponsorship, we would have some facts to moderate our plans... But seriously: thanks to InternetNZ for stumping up with the basics to make sure this conference will become a reality. Anyone else looking to sponsor the best linux conference in the world should send me an e-mail. Soon... :-)

Because of the latest theoretical attack against the SHA-1 digest algorithm (details), I created a new OpenPGP key:

pub 4096R/2789887A 2009-05-11
Key fingerprint = 6454 DC58 6A34 9B42 719A 1E3A 2F66 E80F 2789 887A
uid Norbert Tretkowski <norbert@tretkowski.de>
uid Norbert Tretkowski <nobse@debian.org>
sub 4096R/54CE9E32 2009-05-11


It's signed with my old key 0x0F7A8D01, uploaded to keyservers, and will replace my old key soon.

Would all the paranoid crypto-users please stop flooding Planet Debian with GPG output? And if you just cannot avoid it, please tag those posts meme, because that s what they are. If you really think there s a need for a new key, you re one step ahead of me, because so far, there s only a theoretical attack and the valid question of whether this is actually something to worry about in the context of GPG (or in the context of Git, for that matter). There is no practical exploit out there, and I don t expect one that would endanger your use of GPG any time soon. Of course, we ought to replace the current crypto infrastructure with a new one before the current one is compromised, but that should really be motivated by careful consideration and planning, not by lemming-like behaviour and the infamous tipping point. I ve long been meaning to clean up my key and may also switch to using a new one in the near future. However, I don t think there is an immediate need and I ll take time first to investigate the options RSA is hardly free from problems or an optimal choice. For instance, why would I want to use an RSA key, which is limited in GPG to 4096 bit keys? Do we really want to deal with signatures that are 4-10 times longer than their DSA counterparts? When RSA is broken, will we see a replay of this whole key-replacing frenzy? Wouldn t it make more sense to leverage the current situation and work on pushing/improving the DSA algorithm with larger keys, and to strive towards better algorithms in general, e.g. through SHA-3. If you still need to replace your key, revoke the old one, point at the new one in the revocation reason, and please refrain from abusing feed aggregators from letting the world know. If gpg cannot follow the trust chain after the revocation, please fix it. In the mean time, it is a good idea to use RIPEMD160 instead of SHA-1 for signing, with the following lines in ~/.gnupg/gpg.conf:

personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160
default-preference-list [ ] H10 H9 H8 H11 H3 [ ]

and to set the preferences on your key accordingly:

% gpg --edit-key $KEYID
> setpref [ ] H10 H9 H8 H11 H3 [ ]
> save
% gpg --send-key

Then, make sure RIPEMD160 is being used:

% gpg --clearsign -a </dev/null   grep '^Hash:'

I ll end with a link to a decent write-up on the cryptographic basics of GPG.

Like all those others one can see on Planet Debian creating a new key I just did that. I now have another OpenPGP Key:

pub   4096R/B12525C4 2009-05-10
      Key fingerprint = FBFA BDB5 41B5 DC95 5BD9  BA6E DB16 CF5B B125 25C4
uid                  Joerg Jaspert 
uid                  Joerg Jaspert 
uid                  Joerg Jaspert 
uid                  Joerg Jaspert 
sub   4096R/E075ECFF 2009-05-10

Signed by my old key, uploaded to keyservers, and sometime soon to replace my old 0x7E7B8AC9 one. I wonder how long it will take the new key to reach a similar good place in the WoT statistics like my old had. (Not that its important, just wondering).

Nir Aides, the author of the excellent winpdb debugger, sent me the following email on September 21, 2008, so I asked him if I can copy his email and reply in form of a blog post (so that other people can comment and join the discussion) and he agreed. It took me almost a year to reply, but I made it. :)

Hi Ondrej,

How are you?

I am about to publish a new free software project, a new simple PHP framework, and I am interested in your advice.

You started SymPy and were able to make other people join you and develop it with you.
How did you do it?
How did it happen?
Did you actively call for other people or they spontaneously showed interest and joined you?
Are the other major contributor people who were your friends before you started the project?
Did you need to create or manage the project in a particular way to make it attractive to other people?
Are there things you are aware of that promote collaboration or demote it?

I was never successful in doing the same with Winpdb, which while it became reasonably popular, no one has ever joined me to develop it, except for a notable tutorial contribution by Chris Lasher which was developed independently.

Now with the new project, I am wondering what are my chances of making other people try it and take it on. On the one hand it is a new and fresh code base in an interesting field, on the other hand, why would anyone bother to spend their energy on this new project when they have Symfony or Drupal?

What do you think?

BTW, Ohloh believes you have a median of 19,000 lines of changed code per month since the start of their log. Can this be true? Is this humanly possible? According to it SymPy has over 1,000,000 lines of code? I can't understand these numbers. Winpdb has about 25,000 lines after 3 years of development. And from my experience 1,000,000 lines of code projects need about 20-50 full time developers to work on for 2-5 years which is about 40-250 man years. And as if this is not enough you are listed as owner in a dozen other projects in Google code and have enough time to become an awarded scientist. How is this possible?

http://www.ohloh.net/p/sympy/contributors/

BTW2, do you still use Winpdb? If you find yourself using it less, can you say what are the reasons, or what it would take to make it more useful?

BTW3, How is SymPy doing?

Cheers,
Nir

So my most honest answer how to run a successful opensource project is: I don't know.

But nevertheless I tried to summarize some of my ideas and experience and some guidelines that I try to follow, maybe it will be useful to you Nir, or anyone else.

First of all, there has to be a public mailinglist (easily accessible), public bug tracker, nice webpage, easy to find downloads, frequent releases (once a month is good, but in the worst case at least 4 times a year) and a set of guidelines to follow in order to contribute. So that's a must, if the project doesn't have the above, it's almost impossible to become successful. However, that is just a start, just a playground. There are still many projects that have the above and yet they totally fail to attract developers.

So I think the most important principle is that I always think how to employ other people in what I do. If I have some plan in my head how to do something, e.g. how to move some things forward, I always create exact steps and put it to issues, or our mailinglist, so that each step can be done by someone who is completely new to sympy. So I try to look at things from other people's perspective and think -- ok, I quite like this SymPy project and I'd like to get this done (for example a new release, or something fixed, or implemented), but I have no idea how to start and what exactly needs to be done.

So what I try to do if someone comes to our list and asks for something, is that I create a new issue for it and think how I would fix it if I had time. Then write the necessary steps in the issue and invite the submitter to fix it and I offer help with explaining anything and guiding. Now there are two things that can happen. Either the submitter has time and a will to go forward and in this case he starts wrestling with it and whenever he has some code or a question, I need to find time, review it and offer some way out. Or the submitter is too busy, in which case the instructions simply rest in the issues and the next time someone asks for the feature, the instructions are already there. I don't have estimates how frequent either case is.

When I am working on something myself, I try not to code privately, but also put up issues first and put the steps needed in the issues, so that it's easy for other people to join in.

In general, the most precious value for me is the fact that someone else had to sit down at his computer and wrote the patch. So I do everything possible to get new (or more) people interested in the development. Some people think that only super programmers can do a decent job and it's useless to invest time in people that may just have started with Python. They are wrong. Among the SymPy developers (around 65 people total have contributed patches so far at the time of writing this post), we have all kinds of people. We have people from high school, we have a retired US army engineer, we have physicists, mathematicians, biologists, engineers, teachers, or just hobbyists, who do it for fun. Unfortunately, we do not have many women (I think no patch that made it into sympy was contributed by a woman, but I may be wrong), so if anyone has any ideas how to get more women involved, let me know (I know we have several women fans, so that's a good start:). We have people whose first open source project they ever contributed to was sympy and people who are new to Python.

Many times the first patch that a new potential developer submits is not perfect, usually it's faster for me to write it myself, than to help with the first patch, however my rule is to always help the submitter do that. Sometimes he sends a second patch, or a third, and usually it needs less and less work on my side and it already pays off, because he is then able to fix things himself, if he discovers a bug and sympy has just won a one more contributor.

So I came to the conclusion that all that is needed is an enthusiasm. You don't even have to know Python (as you can learn all these things on the way) and you can still do useful things for us and really spare our time.

To answer another question from Nir's email, SymPy has about 130000 lines of code and another about 20000 lines of tests, so I think those stats are wrong. Also the changed lines of code is in my opinion wrong, we usually have about 250 new patches per release (this depends how often we release and other things).

Yes, I am involved in couple other projects, e.g. Debian, Sage, ipython, scipy, hpfem.org (and couple more), basically everything that has to do with numeric simulation and Python, but my activity there varies. The most time consuming thing in the last couple years was definitely school, I was finishing my master in Theoretical Physics in Prague and then moved to the Nevada/Reno and I just finished my first semester here at PhD in Chemical Physics, and sometimes it was just crazy, e.g. I finished teaching at 7pm and instead of going home and sleep, I stayed in my office, fixed 10 sympy issues that were holding off a release, finished at 1am, went home (by bike, since I don't have a car yet), slept couple hours and then did just school again for a week, other people reviewed the issues in the meantime, and then I made the release (instead of sleeping again). In the last semester it was not unusual that I got home at 1am every week day, then slept most of Saturday to catch up, on Sunday I did some laundry and shopping, and the rest of time I did grading and homeworks for all my classes and teaching, no time for anything else (e.g. no friends, no girls, no rest, no hobby, no opensource stuff, nothing). So sometimes one has to work pretty hard to get through it, but fortunately it's behind me finally, if all goes well, I should be just doing research from now on and have a real life too. Also I am sorry I didn't manage to reply sooner. :)

To answer the other questions:

Are the other major contributor people who were your friends before you started the project?

No, not a single major contributor was my friend before I started the project. Every single one of them become a developer using the procedure I described above, e.g. first showed on the list or in the issues, and maybe even the very first patch was not a high quality one (and if I was stupid and arrogant, or didn't see the big potential, I would just ignore them). But when given a chance, they became extremely good developers and sympy would simply just not be here without them.

Did you actively call for other people or they spontaneously showed interest and joined you?

I very much encourage everyone to contribute, but the initial interest must be in them, e.g. they at least have to show around the mailinglist/issues, so that I know about them. But once I know they are interested in some issue, yes, I try to invite them to fix it, with my help.

One observation I made is that I have to always think in the spirit "how to earn new money, not how to spare the money I already have", e.g. when applied to sympy, how to get new developers, how to develop the new great things etc. Even if I am super busy as I was, I still have to think this way. Once I start thinking how to conserve and preserve what we already have, I am done, finished and that's the road to hell.

If I am open, positive, full of energy, I can see people joining me and we can do great things together. It probably sounds obvious, but it was not for me, when for example some people I worked with, started their own projects, when I got busy, and started to compete, instead of helping sympy out. And I felt betrayed, after so much work that I invested into it and started to become protective. And then I realised that's wrong. I can never stop other people do what they want to do. If they want to have their own project, they will have it. If they don't want to help sympy out, they won't (and what is more important, there is nothing wrong with either of that). It's that simple and being protective only makes things worse.

There is also a question of the license that you use for the project, e.g. one should basically only choose between BSD (maybe also MIT or Apache), LGPL and GPL (there are also several versions of the GPL licenses). Unfortunately the fact is, that there are people who will never contribute a code under a permissive BSD license (because it's not protecting their work enough) and there are also other people who really want to code to be BSD (or other permissive license) so they can sell it and they don't need to consult with lawyers what they are or aren't allowed to do and also so that they can combine it with any other code (opensource or not). It also depends if one wants to combine (and distribute) other codes together. So choosing a license is also important. I believe that for sympy BSD is the best and for other projects (like Sage) GPL is the best and one has to decide on a case by case basis. For Winpdb, I would make it BSD too, since you can get more people using it.

To conclude, SymPy is a little more than 2 years old, and it has been a great ride so far and more things are coming, e.g. this summer we have 5 Google Summer of Code students and people are starting it to use in their research and we plan to use it in our codes at our group here in Reno too, so things look promising. I am really glad, we managed to build such a community, so that when I am busy, as I was the last semester, other people help out with patches, reviews and other things, so that the project doesn't stall and when I got rid of my school duties now, we can move things forward a lot.

So maybe you can get inspired by some of the ideas above. I am also interested in any discussion about this (feel free to post a comment below, or send me an email, or just write to a sympy list about what you think).

Linux policy routing is still incredibly painful if one wants to have more sophisticated routing than just take source and destination IP address for the routing decision . The mechanisms that have been in use seven years ago still work though, and I didn t find any possibility to do it any easier. In this article, I ll try to explain the old mechanisms and hope that somebody from lazyweb will comment and say it can be done so much easier . This is a translation of the Usenet article <gu48cs$rul$1@news1.tnib.de> in de.comp.os.unix.networking.misc in the hope that the english-speaking blogosphere can give additional insights. Given a Linux-based router with one internal network (int0), one perimeter network (per0) and two Internet connections (ext0, ext1) with one IP address each. We need to do source NAT to deliver Internet to the internal and perimeter networks. The internet connection on ext0 will be used for http and https, while all other traffic needs to go out on ext1. The perimeter network is reachable from the outside via destination NAT.

1: ext0:  mtu 1500 qdisc noqueue
    inet 10.81.221.145/29 brd 10.1.221.151 scope global ext0
2: ext1:  mtu 1500 qdisc noqueue
    inet 10.82.83.225/29 brd 10.82.83.231 scope global ext1
3: per0:  mtu 1500 qdisc noqueue
    inet 172.16.1.254/24 brd 172.16.1.255 scope global per0
4: int0:  mtu 1500 qdisc noqueue
    inet 192.168.8.254/24 brd 192.168.8.255 scope global int0

We have the following routing rules:

0:      from all lookup 255
10:     from all lookup main
32:     from all fwmark 0x12e lookup to_ext0
32:     from all fwmark 0x12f lookup to_ext1
32000:  from all lookup defaultroute
32000:  from all lookup defaultroute
32766:  from all lookup main
32767:  from all lookup default

Table main contains all rules for the directly connected networks, but no default route. Both to_ tables have one default route each, pointing to the respective ISP, and the table defaultroute has once more a default gateway pointing to ext1 s gateway. The PREROUTING chain of the mangle table has these rules:

iptables --protocol tcp --dport 80 --in-int int+ --set-mark 0x12e
iptables --protocol tcp --dport 443 --in-int int+ --set-mark 0x12e
iptables --in-int int+ --set-mark 0x12f

and the POSTROUTING chain of the nat table has these:

iptables --match mark --mark 0x12e --out-int ext0 --jump SNAT --to-source 10.81.221.145
iptables --match mark --mark 0x12f --out-int ext1 --jump SNAT --to-source 10.82.83.225

If now somebody from the internal network accesses a web server on the Internet. The outgoig packet will first be marked in the PREROUTING chain, then the routing rules will use the firewall mark to consult the correct routing table and pass the packet back to the packet filter, where the POSTROUTING chain will use the outgoing interface and the firewall mark to SNAT the packet to the correct source IP so that the answer will actually reach us. Has a less ugly way available way to do this become available in the last five years? Or is it still necessary to have the different parts of the networking subsystems play ping-pong with the packet? I particularly dislike that someone not familiar with policy routing will not see any default route in the routing table printed by route or ip route , which will probably be very confusing. Is there any possibility to interact with the routing code without firewall marks, maybe by directly setting a gateway from a firewall rule?

This is going to be a fantastic and exciting Perl summer. During the last week, I received notification that the talk I've proposed for both YAPC::NA and YAPC::EU was accepted. I will be talking about Perl in the Time of Social Networks, which is mainly two broad things: how Perl can actively power a modern social networking site (I'll be releasing a free -as in speech- social network website, similar to Lovd or RailSpace, built with pure Catalyst); and about high-load applications dealing with social networks' APIs and users (a Moose-based universal social network distributor), with Twitter, Facebook, MySpace, Blogger, LastFM, and others. My current contractor has been sponsoring the development and research for this since almost two years now, and we believe it's ready to go public: there's a lot of work backing us up. I'll be presenting the talk in Pittsburgh, PA, on June 23rd at YAPC 10. If you are around the area, come and attend the talk! On YAPC::EU::2009, I will be presenting in Lisbon, Portugal, on August 4th, which is conveniently placed just after DebConf 9, which will happen in C ceres, Spain the week before (I will also be there).

Because of the recently announced attack against the SHA-1 digest algorithm, I finally decided to move away from my old 1024-bit DSA OpenPGP key, landing to a shiny new 4096-bit RSA one. The old key will continue to be valid for some time, but I prefer all future correspondence to come to the new one. I would also like this new key to be re-integrated into the web of trust. I'm attaching a file with
the complete text of the transition, clearsigned by both keys to certify the transition. You can find the transition statement also on http://www.hanskalabs.net/key-transition_20090509.txt . You can check the validity of the file with something like:

$ gpg --decrypt key-transition_20090509.txt   gpg --decrypt

If you need to transition your key too, and you're one of my signees, then let's please coordinate, so that we have the new keys cross-signed, without spurious signatures fromgoing-to-be-revoked keys Thank you for your help.

Attachment	Size
key-transition_20090509.txt	4.03 KB

If you are into sustainable farming this movie will likely catch your fancy.There is a screening here in NYC at the end of May. Supposedly they are going to stream the movie online, which I certainly hope to be the case. A political documentary that is behind bars is really not so useful and is a contradictory project as well. If you are into the idea of farming but live in the city, and New York City in specific, you can attend a Htink workshop on May 17th and start urban farming.

If you are into sustainable farming this movie will likely catch your fancy.There is a screening here in NYC at the end of May. Supposedly they are going to stream the movie online, which I certainly hope to be the case. A political documentary that is behind bars is really not so useful and is a contradictory project as well. If you are into the idea of farming but live in the city, and New York City in specific, you can attend a Htink workshop on May 17th and start urban farming.