I just noticed that hotplug has been removed from unstable, claiming that it has been 'superseded' by udev. On the few occasions that I did try udev, it's always failed for me; as such, I'm still using hotplug on my machines. It's just way more reliable, in my experience; and I don't need automounting of CD-ROMs, or user-space scripts doing setup of kernel-space device nodes, anyway. There are also still some 2000 machines using hotplug, according to popcon.debian.org. That probably includes me, but I don't have 2000 systems. So I have a dillemma, here: either try udev again, or pick up maintenance of hotplug. Or figure out whether it's possible to use udev's hotplugging abilities without its /dev management. That would rock.

There are lots of packages I’ve been doing since I firstly started developing stuff for Debian, that I just didn’t do anything with (apart from using them myself, that’s it). Some are lacking man pages, icons, or things like that. At the time I just didn’t feel like it was too urgent to finish them, because usually finding a sponsor for them would take more effort than making the package itself, but I plan to finish them some time and putting them into the repositories. In any case, I thought that it might be nice to clean them up a bit, compile them against SID, and putting them available somewhere, if someone was interested. Right now I’ve put there:

• construo: Construo is a program for constructing 2D wire-frame objects and let them react on physical forces, its neither a real simulation nor a real game, its just a little toy app which can be a nice way to waste time.
• xspringies: XSpringies is quite similar to construo in its purpose. It’s a 2D mass and spring simulation system. It’s intended use is more like that of a game, than some design package.
• wok: It is an old game made by Kenta Cho. The game objective is very simple. Catch the falling balls by the wok (a flying pan) and throw them to the right. You can control the wok by mouse. To earn more score, you should throw many balls continuously. Collect many balls on the wok, and throw them at the same time. If a ball falls to the lower end of the screen, the game is over.

I plan to keep uploading some of my old packages that are worth it, are in good state, can be compiled against SID right now, and might be of interest to someone, at least until I find some time to finish them properly and upload them to the archive. If anyone is interested in them, they’re welcome!

Started with a cleanup of the account database, to get the official Developers count back to some reality. The first run did include about 400 people, where one or more of the listed categories applied. It started very good - my first run of my script just generated a bounce for every single mail I tried to sent. Turns out its not ok to have “To: user@debian.org user@debian.org>” in your mail text, the setup on master.debian.org doesn’t like this. Oh yes, it really helps to use the right variable for the username part, which doesn’t have the domain appended. Oh well. Then I got that part right, and master did accept all my mails. Just so that I could discover another mistake in my script. Only a cosmetical one, but it helps if you set the From address to the wat alias, not your own, after you finished testing, in case you want to have replies go there directly. Tsss. Now I have to bounce those mails there. Anyway, those are minor things noone, especially the people who got a mail, need to care about, it all just works for them if they reply. And I already got about 40 bounces back, so already nearly 40 accounts to disable. Not all 40, because a few contain enough information so i can try a resend of the mail to a little modified recipient address. The rest is just so that I can’t do anything about them. Well. Ok. There are two people that are using one braindead idiot wanna-be antispam solution which requires you to send some token somewhere to get your mail delivered. Usually I just delete mails then and dont care if they lose, as they obviously do not want to receive mail. I am not sure if I should do it in this case, even if I would like to. After all its their lack of sanity that they do not receive mails… I also got around 60 replies to the pings, with a good number of them resigning from Debian and some others that reconfirm they are active (and mostly point me to their activities). The next WaT run will start about 4 months after this one. Now - 4 months after the previous is over (which would be 6 months from now) or after it started? Probably the first and then have 3 runs a year or something similar. I’m still looking at my scripts to gather the data to enhance them in a way that makes it easy. Like - If someone replies with “Im active” in this run I would like to recheck this if the same user is still a possible WaT target a few runs later.

Following Zack's and Lucas' posts regarding group maintenance of packages: Do I have to AOL with you guys? Yes, I also agree with Zack's both 1 and 2. And I also want to share the bit of experience we have got in this regard in the pkg-perl group. In our case, group maintainership has often saved our collective butts. We have also debated somewhat which way should our packages' maintainership be handled. In the end, our packages' maintainer will (most usually) be the pkg-perl group itself, subscribed through an alias that reaches all of us. Then, every group member that feels identified with the package lists himself as an uploader (note that this does not necessarily have a relation with the last uploads, at least not as strongly as in what the KDE and Gnome groups do, according to Lucas' post - it's closer to the pkg-ruby-extras handling). Of course, there are some packages which I have NMUed in the group's pool - packages I prefer not to have listed in my maintainer page, as I don't usually care too much about them, but I happened to be able to fix a bug with them.
Now, what about the roles of the different group members? Each of us has some skills that make him better for part of the task - i.e., we have an amazingly knowledgeable member, Niko Tyni. He just fixes all the bugs that baffle us. Honest, my best kudos to Niko, he is a good part of our team's success. And then, we have hard-working people as Gregor Hermann, who not only fixes also nice amounts of bugs, but also writes and runs general QA tests throughout our over 300 modules. Neither of them is a DD yet. And of course, many other hard-working folks. Some of us are DDs and try to upload promptly - and, of course, also try fixing bugs. So far, we are in good shape, and we tend not to lag too much. I have taken some vacation periods (both announced and unannounced - sorry :) ), but to my surprise and amazement, my packages tend not to be buggy - Why? Because there is a real team looking after them, and in the end, we keep an eye on each other.
For the pkg-perl group, group maintenance has really worked. We collectively maintain more packages than it would be reasonable for all of us added together as individuals, and they are in a better shape. There are several things we can make better, and we do try to address them - it is not yet heaven, but... :) I'll elaborate later, when I finish a text I'm preparing for presenting at YAPC (it's not that long, of course - During Debconf, I showed advances of it to several people... I just have left it aside). Right now... Well, I have 3hr of sleep left before we leave for a daytrip to the beautiful (but hot and humid!) Veracruz Huasteca. See you on Sunday/Monday!

• German Font Exercise Takes to the Sky
  Wish I had thought of that.
• The GPL and Software as a Service
• C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For
  See also this video, one of the slides says that (security-wise) "C++ is a bad choice in almost any case", which nicely sums up my experience as well...

Stefano Zacchiroli blogs his thoughts about collaborative maintenance. He identifies two arguments/religions about it:

1. it is good because duties are shared among co-maintainers
2. it is bad because no one feels responsible for the co-maintained packages

And he says he stand for the first one. I’m not sure that those two positions really contradict. Sure, collaborative maintenance is a good thing, because it allows to share the load between co-maintainers, which often results in bugs being fixed faster. But collaborative maintenance creates the problem of the dilution of responsabilities, and the dilution of knowledge. In many cases, a single maintainer will have a better knowledge of a package than the sum of the knowledge of all co-maintainers. Also, sometimes, teams don’t work very well, and everybody start thinking that a specific bug is another co-maintainer’s problem. In the pkg-ruby-extras team, we have been trying different organizations over the past two years. We have now settled with the following:

• each package has a “main responsible person”, listed in the Maintainer field
• the team address is listed in the Uploaders field, as well as all the team members that are willing to help with that package (people add themselves to Uploaders manually. Another variant is pkg-kde and pkg-gnome’s automatic generation of the Uploaders field based on the last X entries of debian/changelog (pkg-kde variant, pkg-gnome variant).)
  Interestingly, we discovered that for several packages, nobody was really willing to help, so I’m wondering how other teams with (nb of packages) >> (nb of active team members) work.

Stefano also raises the point of infrastructure issues caused by the switch to the team model. I ran into one recently. My “Automated mails to maintainers of packages with serious problems” are currently only sent to the maintainers of the packages with problems, unless someone has problems in both maintained and co-maintained packages (in that case, all problems are mentioned). I thought for a while about sending mails to co-maintainers as well, but that would mean sending more mails… I might try that and see if I get flamed :-)

Sometimes, putting up an arbitrary limit for your network connection can actually improve the performance.A typical setup will look like this: your computer is connected via 54-100 mBit to a router, which has a DSL line of let's say 2 mBit downstream and 192 kBit upstream (and then tons of other links).When you overload one of these connections, performance can go down a lot.The simples case how this can happen is when you upload data. 192 kBit are the weakest link here, and rather easy to fill up.What happens then is that your computer will start sending out data at his full link speed, until the buffers at the router are full and it starts dropping packets. TCP/IP will then adopt and - lacking 'ACK' packets - slow down sending data. It will likely still keep the send-buffer of the router full.Now if the router isn't very smart, it just keeps a first-in-first-out buffer. As long as you have just this single upload, you don't need to care. But if you have other connections, like a download, you do care.For your download to run at full speed, the sender needs to get those ACK packets from you. They're basically a "got your data, send more" kind of message. Really tiny packets, but essential for signaling.A simple trick you can use now is to limit your bandwith at the sending computer already. Since you're going to limit it just to the next link anyway it doesn't mean it will actually be getting much slower. But your network stack is smarter than the router's (probably). It can send out these ACK packets at a higher priority, so you end up with a better download-and-upload performance.If you know your network connection speed, just use it. Otherwise you can still measure it or guess it. I'm always going for 95% of the speed I see. You might want to limit it a bit more if you are sharing the connection with others.Now enough theory, here's what I use:

IFACE=wifi0
# setup ingress filtering
/sbin/tc qdisc add dev $IFACE handle ffff: ingress
# local network is unrestricted
/sbin/tc filter add dev $IFACE parent ffff: protocol ip \
  prio 10 u32 match ip src 192.168.2.0/24 \
  police conform-exceed ok/ok flowid :1
# incoming internet traffic is limited.
/sbin/tc filter add dev $IFACE parent ffff: protocol ip \
  prio 50 u32 match ip src 0.0.0.0/0 police \
  rate 1500kbit  burst 10k drop flowid :2
# outgoing traffic
/sbin/tc qdisc add dev $IFACE root handle 1: htb default 30
# local network is unrestricted
/sbin/tc class add dev $IFACE parent 1: classid 1:10 htb \
  rate 54mbit burst 15k
/sbin/tc qdisc add dev $IFACE parent 1:10 handle 10: sfq perturb 10
/sbin/tc filter add dev $IFACE parent 1:0 protocol ip \
  prio 10 u32 match ip dst 192.168.2.0/24 flowid 1:10
# internet traffic is limited.
/sbin/tc class add dev $IFACE parent 1: classid 1:20 htb \
  rate 160kbit ceil 196kbit burst 15k
/sbin/tc qdisc add dev $IFACE parent 1:20 handle 20: sfq perturb 10
/sbin/tc filter add dev $IFACE parent 1:0 protocol ip \
  prio 50 u32 match ip src 0.0.0.0/0 flowid 1:20

Long example, I know. The main reason is that I'm not limiting traffic to local computers. Furthermore, I'm also limiting my incoming traffic to use up at most 1.5 mbit of the 2 mbit connection, so my housemates will be able to use the internet as well (Debian mirrors send data fast - fast enough to kick them out of any online game they might be playing...).There is one important detail hidden in there: sfq. This stands for "stochastic fair queueing". It tells the network stack to basically send "one packet for each connection in turn". This way, the small packets needed for download or interactive SSH sessions will get out quickly even when doing a larger upload.It works great for me - I'm having a good download rate, using the 160 kBit upload limit completely (I don't want to completely fill up the 192k upload link either) and I'm actually writing this blog entry remotely via SSH. The lag when writing is okay, probably around 300ms. Without shaping, this wouldn't work this well.(And no: just using 'sfq' for your outgoing traffic is not enough, since the key scheduling is happening at the weakest link. So you have to limit your traffic shaping setup to be just below the actual weakest link.)

At the risk of seeming a self-aggrandizing, I wanted to point folks to a nice biographical profile that Linux.com is running about me upon my election my to the FSF board. I'm pretty honored, and excited, by the whole thing. The article talks a little bit about my road to free software and the FSF board in particular and about some of my ideas about the foundation and its work. There are three little footnotes I thought I would add to what I think is a great article:

• The phrase "rebel with rather too many causes" was a phrase originally directed at protest.net -- a event calendaring system for activists that I was briefly involved in over a summer during college. I like the phrase and use it frequently but I didn't want to take credit for it. Google indicates that it originates in NTK #53 I'm not at all surprised.

• My parents worked as doctors in Kenya, Papa New Guinea, and elsewhere before they had children. This probably doesn't matter to anyone else but they worked with an organization that was like MSF in that it was a humanitarian organization that sent physicians around the world but it was not actually MSF as the article states. I don't think MSF had grown beyond French doctors when my parents were practicing overseas.

• When LWN pointed to the article, and in the original was well, there a focus on some comments I make about non-profit organizations. Since in a context of talk about my political work I just want to clarify my comments in a little more depth here. I think that one problem that has stemmed form Open Source's emphasis on businesses and efficiency is that free/open source software people end up making arguments in business terms: you should use application X because it is more efficient and faster. For many of the folks who have built this whole movement though, and for most in the free software camp, it's about freedom, not efficiency. By targeting businesses, we encounter a skeptical audience. More importantly though, we end up making arguments that, while true, are not the ones that motivate us. I think that low-hanging fruit for free software activists might include groups that already support free software ideas of sharing and user empowerment and that are looking for ways to use free software already. Groups we don't need to be afraid about saying "freedom" around. Not so coincidentally, these are sometimes organizations that I have a lot in common with politically. But that's far from always the case. There's a big group of philosophically aligned organizations in the NGO/non-profit community and the problems keeping them away are often technical. This is good news, of course, since solving technical problems is the free software movement's core competency. This is something I've been thinking about for a long time: Debian-NP was one project I helped start that tried to address this issue. Now, many people involved in the FSF, including myself, have political convictions that go beyond software. I do not want these convictions, and my statements about philosophically aligned organization, to be interpreted as call for a political shift in the organization in mainstream political terms. I deeply respect the way that RMS has kept his political opinions separate from the Foundation's. Biella and I have ever written about the importance of this political demarcation to free software's success. It's certainly not something I would want to change.

Back in the early 1990s, the term "virtual beer" was fairly common in the Linux circles. I still see it used sometimes. The first time it was used, for Linux, as far as I know, was when two guys in England decided they wanted to buy Linus some beers as a "thank you" for writing Linux. Since Linus wasn't traveling much (yet), and they didn't want to come all the way to Finland, they asked me if I would act as a proxy. They'd send me a check, I'd cash it in, and buy Linus beer. I have lost the original e-mail, it seems, but while uncluttering my home I ran into the letter they sent with the check. I scanned in the letter. I have now no memory of who Andrew and Jon are, but if they see this, I hope they'll find the memory of the transaction as nice as I did. (Linus did enjoy the beers.)

More Uploaders, Less Maintainers: Infrastructure Issues When yet another discussion about "is collaborative maintenance good or not?" starts on debian- lists, the average lurker can easily identify two arguments / religions:

1. it is good because duties are shared among co-maintainers
2. it is bad because no one feels responsible for the co-maintained packages

Of the two religions, I stand for the first one. More generally I share the long term aim of decreasing as much as possible the "ownership" of Debian packages; collaborative maintenance is just a tool to achieve the goal. In the meantime, I believe the second religion is supported also by technical deficiencies in some pieces of our infrastructure. In particular some of our developer tools artificially enforce a distinction among Maintainers and Uploaders where it wouldn't be necessarily needed. In the last few days I thought about some of them:

• the BTS by-maintainer reporting mechanism. Years ago, I used to use the BTS as my personal Debian-related TODO list. When I had some time to kill, I just had to point my browser to http://bugs.debian.org/zack@debian.org and a lot of work I had to perform showed up. Today this is no longer the case: most packages of mine are co-maintained and only those with me as a Maintainer show up. Then I have to look for bugs belonging to debian-ocaml-maint@lists.d.o, pkg-vim-maintainers@lists.a.d.o, ... It's tiresome I'll never do that. Hence a request in #430986, shared by other: #225757, #310720.
• dd-list is frequently used to report work needed by maintainers on -devel posts. Since long time it supports a '-u' flag for listing also maintainers, but it's used very seldom, probably just because people do not know about it. It's just a matter of changing a default and developers will find more easily their names in such lists.

Think about such deficiencies, I'm pretty sure we can spot and fix easily a lot of them in our tools. Update: Lucas: I agree that the two arguments do not necessarily contradict, that's why I (initially) called them arguments. Then I moved to "religions", it was an oversimplification: there are of course pros and cons of collab maint. My main argument holds nevertheless: several perceived cons of collab maint are due to artificial distinctions maintainer/uploader in our tools, thanks for providing yet another example ... I want more!

It turns out that if you want to use includes in your .spec file and want the files to be included in the .src.rpm you have to declare those scripts as supplemental sources.

So instead of:
Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....


You have to have:

Name: foo
Version: x.y
Release: z
Summary: foo package
Group: Applications/System
Source: foo.tar.gz
Source101: foo.pre.sh
Source102: foo.post.sh
Source103: foo.preun.sh
Source104: foo.postun.sh
Source105: foo.changelog
Packager: Eddy Petrisor
BuildArch: noarch
BuildRoot: $RPM_BUILD_ROOT
....

In case you want to have the scripts separated in different files and you use them all.

Note: the number in the "SourceXXX" is arbitrary but must be unique.

But mentioning the files as being Source... means you have to write:


%post
%include ../SOURCES/foo.post.sh

%preun
%include ../SOURCES/foo.preun.sh

%postun
%include ../SOURCES/foo.postun.sh


Instead of:


%post
%include foo.post.sh

%preun
%include foo.preun.sh

%postun
%include foo.postun.sh


Which should have been more reasonable...

RPM, please die... or grow some 21st century features... or some sense!!!


Update: Thanks to a few people, I was pointed out I am still not thinking in terms or RPM.
The proper way of writing the include without them looking odd is something like:

%post
%include % SOURCE102

Hi, as everybody else, I'm blogging about the status of my GSoC project, which now has a name: Pancut n. Pancut n is a lintian-like tool to check ISO images generated by debian-cd and friends. It aims to support CDDs, and even Debian-Live CDs. In case you're wondering, the name is a stupid pun about avoiding (skin) burns and unusable debian CDs (Pancut n is a vintage lotion for burns in Argentina, and I think most joungsters won't even recognise the name). In any case, it sounds good :-). Since it has a name, also it has a alioth project page, SVN repository and mailing list. If you want to try it out, just checkout the repository and run:
$ ./pancutan <list of iso files> If you set the environment variable DEBUG to a number greater than zero, you get debugging info. Its dependencies are currently libyaml-perl (or libyaml-syck-perl for faster operation), fuseiso9660 and an user which fuse permissions. Of course, as I've been working in the architecture, there aren't many tests. But you can try the powerpc business card ISO for which pancutan currently detects that it's too big for a business card cd:

$ ./pancutan /media/IOMega/mirror/isos/debian-40r0-powerpc-businesscard.iso
E: image-too-big
 - The ISO file is too big for the target media
 + 73207808

About the architecture. The general idea is that a directory is scanned for modules, "requires" them, and extracts metadata embedded into them (I'm still thinking that this can be separated to delay compiling of modules when they're needed, but I haven't decided it yet). From that metadata, tasks and tags (errors and warnings) definitions are loaded. Also a lot of internal sanity checking is performed. There isn't any fixed order of execution, it's constructed based on the dependencies the tasks define. And it has been thought from the start with parallelisation in mind, although that functionality hasn't been written yet (I'll do it during this week). I have written a draft spec for the plug-ins in the wiki. I have to properly document that, but you can get an idea from it. At this point, I'd like to other, more experienced people take a look at it. So feedback is very welcomed, specially from the people that will use the tool!

Made some progress with gpe-cash today - fixing compiler warnings, stripping out yet more source code and fixing the debian packaging. It does build from SVN but it needs libqof1 >= 0.7.3 which is an unreleased version from QOF CVS.

gpe-cash.

It's now down to < 1Mb installed binaries with less than 500kb of additional libraries (liqof1, libsqlite) compared to a basic Gtk installation. It may creep up to 2Mb all-in by the time the rest of the Gtk code is complete but an Emdebian build should be able to cut that back towards 1.5Mb or so, installed, by dropping the docs. The SQLite backend is fully functional and the default backend. An optional libxml2 backend adds libxml2 and bumps the size requirements substantially but is worth using on the desktop as it adds support for a command-line mode that combines SQL-type queries with XML results. (Eventual plan is to rsync the sqlite from the handheld and use XSL to generate reports etc.) Still a lot smaller than any other double-entry financial package I can find and with none of the dependency problems of the original GnuCash, despite using the same objects. Managed to remove the need for GConf too which is quite handy for an embedded application.

gpe-cash will be my first GPL3 upstream - all the code I'm forking from GnuCash is GPLv2 or later, as is QOF, and GPL3 code can be linked against the LGPL2 or later libgpewidget so I'm making the new Gtk frontend GPL3 or later and I will eventualy release the whole thing under the GPL3 "or later". Thanks to Joe Smith and Anthony W. Youngman for their help with all that. I had it nearly right, just tweaked debian/copyright a bit.

Actually spent a fair bit of time migrating my upstream projects to Anjuta2 and getting used to the new interface. It is a bit twiddly at times and one or two bits are annoying (bit too much eye candy for my liking - repetition of labels and buttons) but overall it's a lot better than when v2 was first uploaded. The integral DevHelp window is handy. I'm still waiting for the svn plugin though and I've no idea what is going wrong with the anjuta manual. It is being installed and yelp can load it when passed the URL directly but I can't get it to show in the normal Gnome Help browser lists - only the man pages show.

The Libby commutation has demonstrated the contempt that the Bush regime has for the US political process, the opinions of the voters and party members, and the reputation of the US. The Talking Points Memo has an insightful analysis. They suggest that an argument could be made for pardoning Libby by claiming that the case is politically based and bogus, such an argument would be difficult to sustain - particularly given the fact that the prosecutor and the judge were Republican appointees. But a commutation is admitting that the case was valid but that Bush wanted to protect a friend - or someone who might inform on him. In either case it’s a very bad thing. As an example here’s a YouTube video of Keith Olbermann making the case for George Bush to act as decently and honourably as Richard Nixon and resign from office. Paul blogs about why embedding media players is bad for the case of web radio. One thing I notice is that there is no convenient or easy way of extracting an embedded youtube video from a web page a quick test in my favourite browser (Konqueror) showed that the YouTube embedded section didn’t even appear. The Debian package youtube-dl allows you to download the Youtube content in a format that can be played with mplayer, but only if you see the link - which seems to not happen if the web site tries to embed it. Avoiding flash is good if you want security or if you want to use a platform other than i386 Linux or Windows and youtube-dl removes what I consider to be the only compelling reason for Flash.

Share This

Mary Gardiner has written a lazyweb post asking about how to solve the problem of laptops being more expensive in Australia than in some other countries. She didn’t post contact details or enable comments on her blog, but that’s OK as this information may be useful to other people. Some years ago I was living in The Netherlands and discovered that the cheapest Thinkpads were available by US mail-order (which didn’t support shipping to other countries). As I was attending a US conference (the Colorado Software Summit) anyway I decided to get a Thinkpad at that time. So I found an friend in the US who was attending the same conference who was willing to receive the Thinkpad for me. I arranged to have the Thinkpad delivered to his doorstep (he assured me that he lived in a safe neighbourhood) and a couple of weeks afterwards I met him at the conference and received my nice new Thinkpad! I’m sure that most people who are active on the net can find someone in the US who they would trust to deliver them a package costing >$1000 and finding such a person who attends the same conference as you shouldn’t be too difficult (I’ve done it). Another way I bought a Thinkpad was that I arranged to have a holiday in London at the same time as the wife of an American who ran a computer store. I met his wife at Heathrow airport and made the final cash payment for the Thinkpad that she delivered. I was worried about a police reaction to seeing a cash sale of a parcel in an airport, but there weren’t any problems… In terms of warranties on laptops, the Thinkpad warrantee is world-wide. You can quote a serial number of a Thinkpad when arranging the warranty repair and they will tell you which country it was purchased in, but they always cover you. I’ve had many Thinkpad repairs, I wear out keyboards regularly through constant use, and due to the extensive travel and hard wear often other parts wear out too. It’s been pretty rare for me to have a warranty repair in the country where my Thinkpad was purchased and I’ve never had a receipt available. It’s never been a problem, they know from the serial number whether the warranty is valid and take care of everything. Thinkpad repair (both under IBM and now under Lenovo) also operates when there is no hard drive in the machine. They don’t even ask a question about the lack of a drive, just note that it doesn’t have one. Update: It has been pointed out to me that importing a laptop without paying tax on it is illegal in most places. But of course if you pay the tax then the total cost will probably be about the same as buying it locally.

Share This

I’m tired of googling for this every time I need it, so I’m blogging about it. Q: How can one redirect all connections to hostA:portA to hostB:portB, where hostA and hostB and in totally different parts of the Internet? A:
echo 1 > /proc/sys/net/ipv4/ip_forward
$IPT -t nat -A PREROUTING -p tcp --dport portA -j DNAT --to hostB:portB
$IPT -A FORWARD -i eth0 -o eth0 -d hostB -p tcp --dport portB -j ACCEPT
$IPT -A FORWARD -i eth0 -o eth0 -s hostB -p tcp --sport portB -j ACCEPT
$IPT -t nat -A POSTROUTING -p tcp -d hostB --dport portB -j SNAT --to-source hostA Connections are masqueraded, that means that, for hostB, all connections are coming from hostA. So be careful.

I'm still lacking the obligatory post-DebConf7 post... These weeks had been intense... So, first of all, thanks to all the DC-team for another wonderful conference. Next year I'll feel how it's done one of the two things that everybody likes but nobody wants to know how it's done. Hint: not sausages. This is the first time I've also attended DebCamp, and it was very useful. Not that I could do any real work, as very few people are able to do that during DebConf, but I managed to do what I planned, that is talk with many people who are working on debian-cd, debian-installer and custom-cdds. I've already uploaded my pictures to a temporary place, whitout captions, until I decide how I will replace the stinko called gallery. And there you can see that I was one of the few that actually wore a kilt during the event —not a proper Debian kilt, but hey... After DebConf, and after a year of hard work, I took a seven days vacation in the UK. So I was able to know Edinburgh (I prefer to hang out with Debian people that doing tourism during the conference, so I only knew the way to the supermarket). I also went to the Arthur's Seat HIll, which was very beautiful, and was only a 1-hour walk from the hostel to the top. Then I did a small visit to Stirling and concluded that castles in Scotland are not that interesting (but go to the Smith Museum!). Then, I went to London for a couple of days (dang, that was expensive!!), visited Marx's tomb, rided near the car bombs, got to know all the nice stuff that the british stole from around the world in the British Museum (it's really great, and free), and went to Cambridge to spend a day (and punting, I even did the punting myself!). Finally I spent my last day walking around that beatiful city, in the Soho and South Bank areas. I don't want to forget to say thanks to Nattie, Kai and Ben for hosting me, you guys rock!! This last week has been very productive. I was working GSoC project, trying to recover from lateness, and staying until late. It was worth it, I have finished settling down the architecture and overall design, and wrote the main program which will coordinate all the tests to be run. It includes from the begining dependency-based scheduling and paralellism, so I hope it will scale well in SMP computers. I also wrote a draft specification for the plugins and description of the running plan in the wiki page. I've also asked for the creation of a Alioth's project, so I can start publishing the code, and get feedback from the people that will use it.

I'm still lacking the obligatory post-DebConf7 post... These weeks had been intense... So, first of all, thanks to all the DC-team for another wonderful conference. Next year I'll feel how it's done one of the two things that everybody likes but nobody wants to know how it's done. Hint: not sausages. This is the first time I've also attended DebCamp, and it was very useful. Not that I could do any real work, as very few people are able to do that during DebConf, but I managed to do what I planned, that is talk with many people who are working on debian-cd, debian-installer and custom-cdds. I've already uploaded my pictures to a temporary place, whitout captions, until I decide how I will replace the stinko called gallery. And there you can see that I was one of the few that actually wore a kilt during the event —not a proper Debian kilt, but hey... After DebConf, and after a year of hard work, I took a seven days vacation in the UK. So I was able to know Edinburgh (I prefer to hang out with Debian people that doing tourism during the conference, so I only knew the way to the supermarket). I also went to the Arthur's Seat HIll, which was very beautiful, and was only a 1-hour walk from the hostel to the top. Then I did a small visit to Stirling and concluded that castles in Scotland are not that interesting (but go to the Smith Museum!). Then, I went to London for a couple of days (dang, that was expensive!!), visited Marx's tomb, rided near the car bombs, got to know all the nice stuff that the british stole from around the world in the British Museum (it's really great, and free), and went to Cambridge to spend a day (and punting, I even did the punting myself!). Finally I spent my last day walking around that beatiful city, in the Soho and South Bank areas. I don't want to forget to say thanks to Nattie, Kai and Ben for hosting me, you guys rock!! This last week has been very productive. I was working GSoC project, trying to recover from lateness, and staying until late. It was worth it, I have finished settling down the architecture and overall design, and wrote the main program which will coordinate all the tests to be run. It includes from the begining dependency-based scheduling and paralellism, so I hope it will scale well in SMP computers. I also wrote a draft specification for the plugins and description of the running plan in the wiki page. I've also asked for the creation of a Alioth's project, so I can start publishing the code, and get feedback from the people that will use it. PS: do MIND THE GAP, please. :-)