Yeah! Of course Sarge was released some time ago. How is it in the press now? A Spanish national newspaper, El Mundo is starting a software collection that is going to be given with printed newspaper. All of the included programs in the collection are for Windows OS, but with the first CD there is included a bonus DVD 9 with Debian Sarge in it. And these days they're advertising the software collection in radio and in the newspaper itself using the "Debian Linux 3.1" DVD as a major point in the collection. They are also going to distribute the ISO online after some time. Of course, I am going to get one.

referring to Red Hat Magazine article for rpm, I tried doing similar with Debian debuild.Rough information is available, but since Debian does not come with debug infos per default,really meaningful result is not easy to get at.To obtain a vmlinux file, I can invoke make vmlinuxfrom the kernel build directory that I invoked make-kpkg.I am not sure how I can use make-kpkg to obtain a debug kernel.On my amd64 box, csum_partial_copy_generic is taking a large chunk of time.arch/x86_64/lib/csum-copy.S.I tried getting the call graph using -c option,but it didn't give me a meaningful answer, maybe I'mmissing something.

I try hard not to hate Redhat, I really do. I don't visibly grimace when someone says "I'm running $REDHAT_DERIVED_DISTRO", and my first solution to "I can't get this to work on $REDHAT_DERIVED_DISTRO" is almost never "just install Debian,Ubuntu ". But Redhat makes it so hard to not beat them with a stick. For instance, I'm working on building a SOE for a client, and so I've got a bunch of scripts (calling random poorly documented and hard-to-find utilities) to help me do that. Naturally, I'm pruning the package list, which requires me to rebuild the list of packages which are on the CD. No problems, I can handle that. Oh, but the tool that builds the package list can't deal with the correct "ordering" of packages in the list. Why is ordering important? Because, and this will make you laugh, the installer can't actually deal with dependencies. Yes, that's right, anaconda will install your packages in any old order you specify, regardless of what is actually needed. Brain-damaged, certainly, but I've dealt with Windows, so this is ultimately a minor setback. The tools for building the packages lists are in a certain package, which I dutifully install. They then proceed to fail horribly. Why, do you ask? Because the script requires python modules from another package. Gee, wouldn't be handy if there was a mechanism by which a package could specify that it needed another package to operate? OH WAIT, THERE IS -- IT'S CALLED DEPENDENCIES, FOR $DEITY'S SAKE! YOU WROTE THE GODDAMN RPM SPECIFICATION, REDHAT, WHY CAN'T YOU ACTUALLY USE SOME OF IT'S FRIGGING FEATURES! But wait, there's more! Installing the package which contains the module doesn't actually make the module accessable to anything else on the system, because the module is installed in some god-forsaken, out of the way location, where Python fears to tread. You need to specify PYTHONPATH to make it work. Apparently someone was sure that specifying absolute paths in scripts (instead of letting the system search it's environment) was a bad idea, but didn't have problem with not putting modules in standard, well-known locations. Then, of course, the (other) tool segfaults. Why? Because it's reading an empty file. Wow. An empty file causes this thing to fall over in a screaming heap. Not "Sorry bub, but your file's empty" just an unceremonious segfault. Wow. Thanks. And that's even before we get around to actually doing an install...

Some japanese companies have requested that the Linux kernel gets a "stable" (whatever) kernel interface for binary drivers. The obvious reason is, that they want to be able to add (illegal!) closed source drivers to the linux kernel. This is a bad idea for a couple of reasons, that have been discussed in a couple of places. Instead I want to show you a couple of examples to illustrate that. First of all, let me name the binary, closed-source drivers of ATI and Nvidia. They totally suck. They are unreliable, cause system crashes, don't work with power management and so on. Is this the type of driver you want? Commercial driver development is not capable of supporting the development speed and models of opensource. Other examples to show you the problems with all the closed source stuff include many wireless access points such as the isl3893 platform or broadcoms AR7. They duefully released the kernel code they used and maybe some drivers, but even the kernel code they touched is broken to large extends (that's why Intersil/Conexant doesn't support https on their isl3893 accesspoints, because they broke their libc in a way they can't get SSL to work on it any more). Now let me give you a good example: USB. There the interface to the hardware was openly and clearly specified, also for many many uses. The result is, that today basically any memory stick and digital camera adhers to this standard, and there is only one driver for it. Thats why they "just work". So instead of requesting a binary driver API in the kernel, these japanese manufacturers should instead start an industry initiative just like USB to standardize on a common stable hardware interface so we don't need a different driver for every hardware. Our real problem is that no hardware is like the other, and nothing is properly documented. And hardware manufacturers earn their money with hardware and haven't got much expertise on software...

Coding Mistakes

I broke my debian administration website yesterday. Predictably enough I’d woken up around 9AM and thought that it would be a good time to make significant refactering changes. Tested them on my laptop, committed them to CVS, then updated the live site. Had a quick play to make sure nothing had obviously broken - but didn’t try to leave a comment on an article. Went to sleep and woke up around 4pm to find 15 emails telling me things were broken. Most mails on the site in a single day! Should be fixed now. But I’ll never again make changes before lunchtime, I’m just not good with the whole sleepy-coding thing.

Things I have never coded: 1

Inspired by Joey Hess’s “Ten years of free software”. Things I have never coded part 1. I have never coded a text editor. *shock* In the past I have written simple wrappers around the various text controls in different environments - for example under Windows I once coded a tabbed text editor called MyNotepad, which featured a novel dockable tree-control to the side which allowed navigation and loading of files easily. When I first started working with Java I coded a similar thing, but with the ability to load external Java .class files as plugins. This editor was called Rosetta, inspired by the band Rosetta Stone (who were in turn inspired by the actual Rosetta stone ) At times I think about text editors. I use them daily, obviously, and I love working with some more than others. My editor is usually GNU Emacs but I’m also partial to Vim. I will use both happily; although neither is pleasant without my personal customizations. Simple text editors are a traditional project for coders, and freshmeat is littered with their discared corpses. Probably the only reason I’ve not started - that and apathy. My ideal editor would be:

• Both curses and x11 based.
• Scriptable (Lua is love?)
• Extensible.
• Portable between (at least) GNU/Linux and Solaris.
• Modeless.

The Canberra Perl Users Group is having one of its extremely irregular meetings next week. If you're in Canberra, or will be on November 2, let me know. The last one wasn't too bad. http://mail.pm.org/pipermail/canberra-pm/2005-October/000146.html

Today I upgraded daedalus to 2.6.14. I had to backport yaird to stable, which wasn't a big deal. It's available here if you're interested. The kernel package for 2.6.14 from unstable worked fine otherwise. I had two motivations behind upgrading - inotify and another look to see if the situation with IPMI had changed. Well inotify just works, and is the bomb. I'm going to have lots of fun with it. IPMI, on the other hand is still broken, which makes me sad. As I've previously pointed out by way of example, LAN access to the base-board management controller via IPMI is impossible after Linux shuts down the interface. It's supposed to work, but the way Linux does it seems to stop it from working. I'd read that the problem was resolved in 2.6.12, and so dutifully tested it out on daedalus to my detriment. I also tested it on 2.6.14, but again, had the same problem (I remembered to schedule a deferred reboot this time). So IPMI with a box running Linux is all good as long as the box is actually running. I suspect if the box panicked and/or hung itself, it'd also be useful for rebooting it, but if you shut the box down and remove power, IPMI won't allow you to turn it back on again.

My first trip. We visited the Silberloch, one of the more difficult caves in our region. Maybe not the best way to start caving for me, but I really enjoyed it. I was there with four guys from the Caveseekers, all of them quite experienced. We have been about four hours in the cave. That was definitely not the last time I did that, but I need my own equipment next time.

The shuttle xpc that I decided to get as a media server / d-i test machine instead of buying a second used laptop arrived today. Just after I'd gotten that Asus router that seemed to die in Oldenburg back to working. I didn't really spend much time choosing it on ebay from amoung the other used shuttle machines on there. For example, I had thought this was a new enough AMD chipset to be an amd64, but it's not, it's a k7. This probably shows how out of touch I am with current hardware. Since I didn't buy based on wanting an amd64 particularly, I'm pretty happy with it just the same. Especially since it already has a 4 in one memory stick reader that includes a compact flash reader, so I can stop messing around with compact flash on pcmcia for work and just set up boot disks for my arm machines using the shuttle pc on my desk. And it can also serve as the terminal server for my arm boards. I think it'll run vmware fast enough to do some good d-i development, and it can also boot from USB, although not using d-i (yet). And netboot, so if vmware feels pokey and I can do without the music that's the only other thing it is likely to be doing, I can reboot it for d-i tests too. Reasonably quiet too, although it'll probably be turned off at night. Anyway, I christen thee.. dodo.

This is by far the most stressful long period I can remember in my life. I was quite in control of things approximately until around June. Since then, things have been falling over me in a quick and heavy sucession - First of all, being co-organizer at Debconf was quite hard. I had run conferences before, but nothing ever like this - And, I should add, I never had a German boss running the show. [friend="Stockholm"], as a project leader, you really rule... But whoever works with you should be warned: It is not easy.
Gunnar's Rule of Future Life No. 2: It's easier to be the coordinator (remember I was officially the Tyrant for three years at CONSOL? :) ) than to be in the immediately subordinate team.
Back home, I expected the regular post-vacation rush, so having a hard August -trying to make everything on time- was expectable and OK. I don't remember exactly what projects was I in during August/September (I remember some minor stuff, but I think adding it all together was the mistake). There is one thing I did, though: Accepting way too many invitations as a speaker, at least one every two weeks. And, as many of you know, you cannot just travel somewhere and keep working - When I am at a conference, I want to get to talk with the people there, I want to know what are they interested in (why they invited me in the first place), and make friends with them. But this time it was (as it happens every year - Why are most conferences stuck together September-November?) just way too much.
Gunnar's Rule of Future Life No. 2: Be careful on what you accept. It's easy saying "yes" to a conference. It's hard keeping sanity afterwards.
Ok... I have been going places. For example, two weeks ago I was to San Luis Potos . Instead of staying there for two days, I left my office at 7PM, took the metro to the bus station, got the bus at 9PM, arrived at 2AM, went to my hotel, woke up at 7:30AM, had breakfast, coded for ~1hr, went to the conference theater, delivered my talk at 11AM, went for a quick lunch (which became a takeaway order) at 1:15PM, got on my bus at 2PM, arrived back in Mexico City at 7PM, got to a (fucking long) meeting at 8PM, left the meeting at 12AM, and finally got back home at 1AM. Fun, huh?
Gunnar's Rule of Future Life No. 3: Yes, it's fun to travel. It is much more fun to travel when you actually get to know the place!
...And pressure has not given way. As soon as I finish with one project, there is another one demanding my attention right away. October has been more than hectic. I had to cancel two invitations (on which I was to go to two cities each time) I was quite looking forward to, in Peru - I am very sorry, friends at Lima, Moquegua, Tacna and Arequipa... But I won't make it there this year. I am specially frustrated by not being able to make it to Concladeb in Arequipa - I really want to see DebianPeru/DebianArequipa's good work! And I am specially sorry on canceling today my trip to Moquegua, after they had already booked (and paid) for the tickets... It seems the money will not be lost after all, but I was such a pain in the ass for them, it is not fair I am cancelling... But anyway.
Gunnar's Rule of Future Life No. 4: Remember to learn from past experiences - It feels incredibly as a deja-vu from last year.
I hope I am not spoiling any surprises: Today, instead of blogging, I am supposed to be setting up the Comas server for Debconf6. Even with all of my worries, yes, I am still determined to be the man behind the show for Debconf. It will be in Oaxtepec, don't worry, and it will be a huge success. So let me finish this post quick, and it will be sooner you can register for it ;-) There are still too many points to work on Comas, though. I am setting up a tweaked version, against my will, but with the commitment to fix it transparently and soon. Oh... Yes, and I still have to coordinate with the locals here, as it's taking forever for us to open the fscking bank account so we can start receiving funds and paying money. Did I mention Debconf would be in Mexico? Ok, I will do my best not to make lateness the norm.
Gunnar's Rule of Future Life No. 5: Try not to bore your audience with too many details. Remember you have to work, and somebody might complain you lose too much time blogging!
But before I leave you alone: You might ask why do I mention the addiction in my post title... Well, because I have started treating my main addiction. It is really not easy, and I don't ever want to know what is it like to have a chemical addiction, like people who abuse drugs. If you have seen me face to face, it should be obvious: I have a very strong addiction to food. For one month already, I have been as conscious as I can every time I open my mouth - And, yes, it was not just three times a day. I have made some advances (sorry, I cannot really measure it, as home scales make it only to 120kg). Today is a big day for me: I was admitted in a pilot obesity control follow-up treatment at my University's sports health direction. I am very happy about this, as I do need mentoring and hand-holding. This is a seriously difficult process to follow, and I really hope to carry it thoroughly. Fortunately, my health has been perfect until now - But I cannot abuse myself forever.

Systems 2005 Another year, another Systems. This year, however, sadly the first time without Jens, so organization was harder than usual. C&L again provided an Open Source area where we had a booth along with GNOME, KDE, the several BSDs, PostgreSQL and some smaller Open Source projects. As we were not able to build up the booth on Sunday already, there was only a pretty bad location left on Monday, facing towards the wall. Roland Stigge provided a huge 1,5 by 1,5 metre Debian swirl banner, which we mounted in the vicinity of the (too small for that) booth. Michael Ablassmeier brought a Shuttle PC and a TFT display so we could show visitors around the Debian desktop and point them towards further information on the internet. Credativ again kindly shipped posters and flyers. We sold the former and distributed the latter to passing visitors. Unfortunately, Credativ did not receive any LinuxTag DVDs this year, and we were unable to obtain some from other people (apparently they are spared for LinuxWorldExpo in Frankfurt next month, though most visitors there should know Debian already I guess), so we only had about 30 DVDs, which were left from the pack I took back from LinuxTag myself. We sold those for 2 EUR, and later distributed some shiny new Breezy CDs the GNOME booth acquired on Thursday and had some Sarge CDs pressed at a nearby CD production booth which we sold for 2 EUR as well. After some initial doubts on whether we would be able to properly man the booth, it turned out that the local Debian community was enough to guarantee presence except for Friday morning. Michael Ablassmeier, Erich Schubert, Simon Richter, Roland Stigge and Rene Engelhard manned the booth besides me. So we were in the fortunate position that we had two people at the booth most of the time while shuffling around personnel, while most other booths were operated by the same one or two people throughout the week. This year, almost all people I asked (I usually offered a flyer and asked "Do you know Debian already?" to all passing visitors, unless they quickly tried to run through our territory) knew about Debian at least somewhat, and surprisingly many people said they had Debian installed and were happy with it. Thanks to the Sarge release and the almost-official amd64 archive (the respective lack of which were by far the most prominent questions last year), we had almost no recurring questions to answer; probably the most frequent question was about Ubuntu and our relationship with it, but those were pretty scarce and I expected much more of that. Likewise, only very few people were unhappy about Debian (far outweighed by the happy bunch), and most of that seemed to be due to specific technical issues rather than any general reservations about the Debian development or community processes. Most of the remaining questions were pretty specific, e.g. people having issues installing Debian on their hardware or trying to do some exotic stuff. To summarize, it was a nice having a booth again and getting in touch with visitors and users. I did not see much else of Systems this year due to being busy with university as well, but I do not think it would have been worth it anyway. Murray Cumming and Joerg Kress (who were managing the GNOME booth) helped me dismantle the booth and carry back the hardware and leftovers on Friday evening and we decided to have dinner together at a nice pub in Munich.

ALUG had a kit-meet last Sunday and there's some description of what happened on the mailing list. A week or two ago, there was some discussion about improving the ALUG wiki. I think it was broken while trying to cure the repeated spam attacks while I was abroad in the summer. The immediate problem has been fixed now and there was an offer of renovation, which I'm trying to take up. Around the same time, I outlined some planned improvements for the main site which are described on their own page now. The release announcement provoked a typical discussion about how the site needs rewriting to do things it already does. :-/ I hate it when that happens. All the world's a webmaster these days. One practical improvement idea and one good suggestion so far, too, so maybe it's worth it :-) A retheme competition was started at Brett Parker's web site, and there's a later version of my entry too.

The moral of the story is always, always use at to schedule a reboot shortly in the future, no matter how harmless you think something is... Today I stopped procrastinating about upgrading daedalus's kernel to 2.6.12 and did it. That worked fine. The reason for the upgrade was that I'd read somewhere that 2.6.12 fixed the problem with things like Dell's Baseboard Management Controller, where if you downed the interface in Linux, it downed it so far so that the BMC (which does some funky low-level physical interface sharing) also stopped being remotely accessible. So I upgraded, hopeful in the fact that if I were to ever remotely shut down daedalus, I could turn it back on or reboot it remotely with ipmitool. I thought I'd test this, so I did this:

daedalus:~# ip l s dev eth0 down; sleep 10; ip l s dev eth0 up

and promptly kissed daedalus goodbye. Not just for 10 seconds, for until I could get the colo guys to kick it in the guts for me. Grrr. At least I determined that the problem appears to persist. If I down an interface in Linux, it's down for the BMC as well. That sucks.

The new stovepipe seems to work great, although something wants to burn off of it at "roaring blaze" setting. I'm disappointed that Anna's decided to avoid a wood stove. Yes, they're dangerous and dirty and a lot of work, but the warmth and general niceness of a fire and wood make up for it. Reflexes are amazing things. I can't remember seeing the branch coming up past my glasses to my eye, but apparently it got closed in time, since I didn't put it out when carrying brush from the line cut yesterday. It's been a bit weepy since, and after waking up with it nearly shut, I empathise with all those poor kittens with gummed up eyes. Oh yeah, I bought a used amd64 shuttle XPC on ebay. The idea is that it will hopefully be fast enough to run vmware on for some serious d-i development work, while also doing things like playing music and being a file server. And quiet enough to be in the same room with.

On Friday and Saturday this year's Berlinux event took place in Berlin, Germany. It's a regional event with a small exhibition and a conference program. The Debian project took part with three talks and a booth, plus Skolelinux, and two companies that demonstrated their Debian-based distribution. On Friday a lot of students visited the exhibition area since it was built more or less in the middle of the usual university maze. The entire exhibition had to be dismantled during the night if the equipment shouldn't get lost in the morning. That way we had the fortune to see more of the building of the Technical University of Berlin that is quite impressive. The building was old, with huge walls and a very high ceiling, paired with wide and voluminous stairs and hallways. A very classical and very nice building. On Saturday there were more visitors and more parallel tracks. It was a bit unfortunate that the exhibition was split into two levels of the building and that the conference rooms were farer away from the exhibition. Getting there meant to walk through the usual University maze since Berlinux was embedded there and not separated from it.

Planets are a fairly common method to aggregate blogs. They are especially pervasive in the FOSS world, with planets for Debian, Gnome, KDE, and many others. I find planets as a useful resource for a community to give a single place for the communication and to check for updates. The usual method of communication in blogs is a reply in a post, the planet makes the replies come in the same page for the reader with little context loss. For this reason I'm also fond of setting up planets myself for those communities that lack them, and so I setup planets for FOSS-IL for Israeli blogs about FOSS issues (mostly in Hebrew), Planet (former) Advogato for former Advogato bloggers and the latest one is Planet MicroISV for MicroISVs. I was asked to provide some (tutorial help something) on setting up a planet, and this post is the answer to that request.

---

The PlanetPlanet program is a very common RSS feed aggregator, it works with most feeds and is fairly tolerant to non-standard-conforming feeds. It is also relatively low maintenance, which is why I chose it for my aggregators. Prerequisites The first thing you'll need is to make sure you have Python 2.2 or better installed. If you're on a sane OS, you can just do apt-get install python2.3 otherwise you are left to fend for yourself. For the Windows folks there is ActivePython. Another would be prerequisite is GNU Arch or GNU Arch or Bazaar, two implementations for the Distributed Revision Control algorithm which was pioneered in GNU Arch. Bazaar would be more user friendly, but both IMNSHO are horrendous user-interface wise. Which is why I provide a snapshot of the latest revision for your benefit. Install Installation would be fairly simple, just unpack the tar.gz and it's installed, nothing else needs to be done, except configuring it. The snapshot I provided is just a raw dump of the arch repository, it is useful as is since you can update the installation as needed by just updating and merging with Arch/Bazaar. This will not be covered here. Too much of a trouble for now, and the PlanetPlanet development is at the pace of a snail carrying an elephant, don't expect updates in the near future. Configure I assume you have in mind the list of blogs you want to put on the planet. It need not be comprehensive, a few blogs to start would be good enough. It's trivial to add more as you go. In the planet directory you should copy the examples directory to a new one, say myplanet, copy the output directory to myplanet-output and edit the myplanet/config.ini file. At the minimum you should change the following variables:

• name – The name of your planet
• link – The URL where you planet will live, used inside the feeds the planet exports
• owner_name and owner_email – obvious isn't it?
• output_dir – that should be myplanet-output according to the instructions above
• template_files – change and replace examples with myplanet

The next stage would be to replace the existing blog listed in the config.ini file with your own list. The example is there and is trivial to follow, the entry for a blog looks like:

[http://baruch.ev-en.org/blog/index.rss2]
name = Baruch Even

Where the feed URL is in square brackets and the name of the blog is the name. There are various games that are possible with the templates but we'll ignore them for now and let you learn them from the examples provided by the authors. The next stage is just to run the planet on the new files, we will use the defaults for the rest.

python planet.py myplanet/config.ini

The planet will work for a while, churn out various uninteresting messages and generate the files we asked it for in the myplanet-output. You can now inspect the files in the output directory, load them in a browser and enjoy. Tweaks So you haven't left yet? Want some more info? One obvious question is now that we have the files, how do we serve them to the world so everyone can enjoy our creation? First, you should ask yourself if the world really cares... you do, ah?! OK. If the world cares enough it will find a way to show you how to do it. Since it depends on your OS, web server and various configurations, I can't help you on this. This is left as an exercise to the reader. The configuration in config.ini should be fairly obvious and is well commented. The look of the site depends on two factors, the HTML that is generated, which is a clean HTML version 4.01 and has all formatting controlled by the CSS file which was kindly provided in the outputs directory. The templating code is very simple, it has two operations, TMPL_LOOP and TMPL_VAR. TMPL_LOOP will loop over a variable, usually the Channels variable. And the TMPL_VAR operator will emit that variable, there are the global vars and the loop vars. The best way to figure it out is to use the existing templates as a building block, they are fairly easy to understand. Enjoy your new Planet!

This are some random thoughts I posted to the G-Wrap development mailing list regarding creating bindings for C libraries for Scheme. Although partly G-Wrap specific, it also might be of interest to other Scheme hackers. I’m not at all convinced my effort to make G-Wrap support Scheme 48
makes much sense at all, for these reasons:

• Most of G-Wraps complexity stems from C code generation, which is
  not necessary with a Scheme-level FFI, such as Scheme 48 and PLT
  Scheme provide. It seems a different, more simple tool, with the
  different features would be much more suitable: With a Scheme-level FFI, you can conviniently bind a given C API
  by writing Scheme code; it seems backwards to use a code
  generator, as you have one in Scheme itself in the form of
  macros. The problem is a different one: extracting certain
  information from the C API that is not (convieniently) available
  without invoking a compiler, such as the values of C macros and
  enumerations. With the code-generation approach, this knowledge is
  compiled into wrapper functions (and thus hidden away). With a
  tool I envision, that knowledge would be _extracted_ at the tools
  run time, by generating simple C programs that print those values
  in S-expression form, invoking the compiler on the C code, and
  running the resulting executable. This is quite different from
  what G-Wrap does, and retrofitting such functionality into G-Wrap
  would make it even more complex. I can really recommend reading the paper about the PLT FFI, linked
  from the CSW, to see how expressive a Scheme-Level FFI is; hiding it
  below a code generator only takes away from that.
• Now that my focus has shifted from Guile to Scheme 48, and
  portable Scheme in general, I view my rewrite using GOOPS
  ambivalently; the rewrite has certainly made G-Wrap more flexible
  and extensible, and probably given it a clearer structure,
  however, due to GOOPS’ use of keywords (while they are
  R5RS-compatible and supported by some other implementations),
  GOOPS is fundamentally non-standard, without touching the core of
  implementations that don’t provide #:foo-style keywords it isn’t
  possible to implement it on other Schemes. IMO, G-Wrap supporting
  multiple back-ends only makes sense when it also is able to run on
  these implementations, or else it probably won’t get much usage.

So in short: G-Wrap’s future looks brightest when staying a Guile
(-only) tool; a much more simple, portable C-binding tool can be
achieved by:

• Implementing a PLT-style FFI. This already goes a long way towards
  easing the work of creating bindings; I wrote a simple mysql
  binding for Scheme 48 in 135 lines of pure Scheme. Actually, the
  RTI (run time information) layer in G-Wrap can be seen as a
  half-implementation of that approach; implementing a subset of the
  PLT FFI for Guile based on that part of G-Wrap would be not very
  hard (speaking from my experience on doing the same thing for
  Scheme 48).
• Supplement that with tools that can extract the low-level C API
  information from headers, by parsing and compilation (as outlined
  above). Also G-Wrap could profit from a C header parser, as
  writing the declarations for the wrappers is quite tedious if more
  than a few functions are involved. I haven’t really looked at it,
  but scheffig is a tool that looks similiar to G-Wrap on a
  superficial level (generates C wrapper functions) and leverages
  the FCC C parser written by Mike Sperber, which probably is quite
  portable.
• The low-level API information, as extracted in the above step still
  doesn’t contain enough information for useful Scheme bindings, as
  part of the information needed for binding a C library are only
  available in its documentation, for example the semantics of memory
  allocation, for example whether a “double *” function argument in
  fact an array of a certain size, specified by another argument of
  that function, or a output argument. This information would be
  encapsulated in hand-written high-level bindings that make use of
  the automatically generated low-level bindings that result from
  header parsing.

This are some random thoughts I posted to the G-Wrap development mailing list regarding creating bindings for C libraries for Scheme. Although partly G-Wrap specific, it also might be of interest to other Scheme hackers. I’m not at all convinced my effort to make G-Wrap support Scheme 48
makes much sense at all, for these reasons:

• Most of G-Wraps complexity stems from C code generation, which is
  not necessary with a Scheme-level FFI, such as Scheme 48 and PLT
  Scheme provide. It seems a different, more simple tool, with the
  different features would be much more suitable: With a Scheme-level FFI, you can conviniently bind a given C API
  by writing Scheme code; it seems backwards to use a code
  generator, as you have one in Scheme itself in the form of
  macros. The problem is a different one: extracting certain
  information from the C API that is not (convieniently) available
  without invoking a compiler, such as the values of C macros and
  enumerations. With the code-generation approach, this knowledge is
  compiled into wrapper functions (and thus hidden away). With a
  tool I envision, that knowledge would be _extracted_ at the tools
  run time, by generating simple C programs that print those values
  in S-expression form, invoking the compiler on the C code, and
  running the resulting executable. This is quite different from
  what G-Wrap does, and retrofitting such functionality into G-Wrap
  would make it even more complex. I can really recommend reading the paper about the PLT FFI, linked
  from the CSW, to see how expressive a Scheme-Level FFI is; hiding it
  below a code generator only takes away from that.
• Now that my focus has shifted from Guile to Scheme 48, and
  portable Scheme in general, I view my rewrite using GOOPS
  ambivalently; the rewrite has certainly made G-Wrap more flexible
  and extensible, and probably given it a clearer structure,
  however, due to GOOPS’ use of keywords (while they are
  R5RS-compatible and supported by some other implementations),
  GOOPS is fundamentally non-standard, without touching the core of
  implementations that don’t provide #:foo-style keywords it isn’t
  possible to implement it on other Schemes. IMO, G-Wrap supporting
  multiple back-ends only makes sense when it also is able to run on
  these implementations, or else it probably won’t get much usage.

So in short: G-Wrap’s future looks brightest when staying a Guile
(-only) tool; a much more simple, portable C-binding tool can be
achieved by:

• Implementing a PLT-style FFI. This already goes a long way towards
  easing the work of creating bindings; I wrote a simple mysql
  binding for Scheme 48 in 135 lines of pure Scheme. Actually, the
  RTI (run time information) layer in G-Wrap can be seen as a
  half-implementation of that approach; implementing a subset of the
  PLT FFI for Guile based on that part of G-Wrap would be not very
  hard (speaking from my experience on doing the same thing for
  Scheme 48).
• Supplement that with tools that can extract the low-level C API
  information from headers, by parsing and compilation (as outlined
  above). Also G-Wrap could profit from a C header parser, as
  writing the declarations for the wrappers is quite tedious if more
  than a few functions are involved. I haven’t really looked at it,
  but scheffig is a tool that looks similiar to G-Wrap on a
  superficial level (generates C wrapper functions) and leverages
  the FCC C parser written by Mike Sperber, which probably is quite
  portable.
• The low-level API information, as extracted in the above step still
  doesn’t contain enough information for useful Scheme bindings, as
  part of the information needed for binding a C library are only
  available in its documentation, for example the semantics of memory
  allocation, for example whether a “double *” function argument in
  fact an array of a certain size, specified by another argument of
  that function, or a output argument. This information would be
  encapsulated in hand-written high-level bindings that make use of
  the automatically generated low-level bindings that result from
  header parsing.

Dear World, ping is a very useful command. It lets me see if a host is up. If you block ICMP ECHO/REPLY then I instead have to play the "Guess what service might be listening" game. Or I assume your machine is down and might worry (because I care). So please don't do it. I really don't see what you're trying to gain; it strikes me as firewalling without actually thinking about it. Are you by chance ignoring things like destination unreachable as well? And breaking PMTU discovery? Well done you.