Ren Carmille (8 January 1886 25 January 1945) was a French humanitarian, civil servant, and member of the French Resistance. During World War II, Carmille saved tens of thousands of Jews in Nazi-occupied France. In his capacity at the government's Demographics Department, Carmille sabotaged the Nazi census of France, saving tens of thousands of Jewish people from death camps.

Gino Strada (born Luigi Strada; 21 April 1948) is an Italian war surgeon and founder of Emergency, a UN-recognized international non-governmental organization.

Il morbo di K una malattia inventata nel 1943, durante la Seconda guerra mondiale, da Adriano Ossicini insieme al dottor Giovanni Borromeo per salvare alcuni italiani di religione ebraica dalle persecuzioni nazifasciste a Roma.[1][2][3][4]

Stage races

With the speed of network hardware now reaching 100 Gbps and distributed denial-of-service (DDoS) attacks going in the Tbps range, Linux kernel developers are scrambling to optimize key network paths in the kernel to keep up. Many efforts are actually geared toward getting traffic out of the costly Linux TCP stack. We have already covered the XDP (eXpress Data Path) patch set, but two new ideas surfaced during the Netconf and Netdev conferences held in Toronto and Montreal in early April 2017. One is a patch set called af_packet, which aims at extracting raw packets from the kernel as fast as possible; the other is the idea of implementing in-kernel layer-7 proxying. There are also user-space network stacks like Netmap, DPDK, or Snabb (which we previously covered). This article aims at clarifying what all those components do and to provide a short status update for the tools we have already covered. We will focus on in-kernel solutions for now. Indeed, user-space tools have a fundamental limitation: if they need to re-inject packets onto the network, they must again pay the expensive cost of crossing the kernel barrier. User-space performance is effectively bounded by that fundamental design. So we'll focus on kernel solutions here. We will start from the lowest part of the stack, the af_packet patch set, and work our way up the stack all the way up to layer-7 and in-kernel proxying.

af_packet v4 John Fastabend presented a new version of a patch set that was first published in January regarding the af_packet protocol family, which is currently used by tcpdump to extract packets from network interfaces. The goal of this change is to allow zero-copy transfers between user-space applications and the NIC (network interface card) transmit and receive ring buffers. Such optimizations are useful for telecommunications companies, which may use it for deep packet inspection or running exotic protocols in user space. Another use case is running a high-performance intrusion detection system that needs to watch large traffic streams in realtime to catch certain types of attacks. Fastabend presented his work during the Netdev network-performance workshop, but also brought the patch set up for discussion during Netconf. There, he said he could achieve line-rate extraction (and injection) of packets, with packet rates as high as 30Mpps. This performance gain is possible because user-space pages are directly DMA-mapped to the NIC, which is also a security concern. The other downside of this approach is that a complete pair of ring buffers needs to be dedicated for this purpose; whereas before packets were copied to user space, now they are memory-mapped, so the user-space side needs to process those packets quickly otherwise they are simply dropped. Furthermore, it's an "all or nothing" approach; while NIC-level classifiers could be used to steer part of the traffic to a specific queue, once traffic hits that queue, it is only accessible through the af_packet interface and not the rest of the regular stack. If done correctly, however, this could actually improve the way user-space stacks access those packets, providing projects like DPDK a safer way to share pages with the NIC, because it is well defined and kernel-controlled. According to Jesper Dangaard Brouer (during review of this article):

This proposal will be a safer way to share raw packet data between user space and kernel space than what DPDK is doing, [by providing] a cleaner separation as we keep driver code in the kernel where it belongs.

During the Netdev network-performance workshop, Fastabend asked if there was a better data structure to use for such a purpose. The goal here is to provide a consistent interface to user space regardless of the driver or hardware used to extract packets from the wire. af_packet currently defines its own packet format that abstracts away the NIC-specific details, but there are other possible formats. For example, someone in the audience proposed the virtio packet format. Alexei Starovoitov rejected this idea because af_packet is a kernel-specific facility while virtio has its own separate specification with its own requirements. The next step for af_packet is the posting of the new "v4" patch set, although Miller warned that this wouldn't get merged until proper XDP support lands in the Intel drivers. The concern, of course, is that the kernel would have multiple incomplete bypass solutions available at once. Hopefully, Fastabend will present the (by then) merged patch set at the next Netdev conference in November.

XDP updates Higher up in the networking stack sits XDP. The af_packet feature differs from XDP in that it does not perform any sort of analysis or mangling of packets; its objective is purely to get the data into and out of the kernel as fast as possible, completely bypassing the regular kernel networking stack. XDP also sits before the networking stack except that, according to Brouer, it is "focused on cooperating with the existing network stack infrastructure, and on use-cases where the packet doesn't necessarily need to leave kernel space (like routing and bridging, or skipping complex code-paths)." XDP has evolved quite a bit since we last covered it in LWN. It seems that most of the controversy surrounding the introduction of XDP in the Linux kernel has died down in public discussions, under the leadership of David Miller, who heralded XDP as the right solution for a long-term architecture in the kernel. He presented XDP as a fast, flexible, and safe solution. Indeed, one of the controversies surrounding XDP was the question of the inherent security challenges with introducing user-provided programs directly into the Linux kernel to mangle packets at such a low level. Miller argued that whatever protections are expected for user-space programs also apply to XDP programs, comparing the virtual memory protections to the eBPF (extended BPF) verifier applied to XDP programs. Those programs are actually eBPF that have an interesting set of restrictions:

• they have a limited size
• they cannot jump backward (and thus cannot loop), so they execute in predictable time
• they do only static allocation, so they are also limited in memory

XDP is not a one-size-fits-all solution: netfilter, the TC traffic shaper, and other normal Linux utilities still have their place. There is, however, a clear use case for a solution like XDP in the kernel. For example, Facebook and Cloudflare have both started testing XDP and, in Facebook's case, deploying XDP in production. Martin Kafai Lau, from Facebook, presented the tool set the company is using to construct a DDoS-resilience solution and a level-4 load balancer (L4LB), which got a ten-times performance improvement over the previous IPVS-based solution. Facebook rolled out its own user-space solution called "Droplet" to detect hostile traffic and deploy blocking rules in the form of eBPF programs loaded in XDP. Lau demonstrated the way Facebook deploys a three-part chained eBPF program: the first part allows debugging and dumping of packets, the second is Droplet itself, which drops undesirable traffic, and the last segment is the load balancer, which mangles the packets to tweak their destination according to internal rules. Droplet can drop DDoS attacks at line rate while keeping the architecture flexible, which were two key design requirements. Gilberto Bertin, from Cloudflare, presented a similar approach: Cloudflare has a tool that processes sFlow data generated from iptables in order to generate cBPF (classic BPF) mitigation rules that are then deployed on edge routers. Those rules are created with a tool called bpfgen, part of Cloudflare's BSD-licensed bpftools suite. For example, it could create a cBPF bytecode blob that would match DNS queries to any example.com domain with something like:

    bpfgen dns *.example.com

Originally, Cloudflare would deploy those rules to plain iptables firewalls with the xt_bpf module, but this led to performance issues. It then deployed a proprietary user-space solution based on Solarflare hardware, but this has the performance limitations of user-space applications getting packets back onto the wire involves the cost of re-injecting packets back into the kernel. This is why Cloudflare is experimenting with XDP, which was partly developed in response to the company's problems, to deploy those BPF programs. A concern that Bertin identified was the lack of visibility into dropped packets. Cloudflare currently samples some of the dropped traffic to analyze attacks; this is not currently possible with XDP unless you pass the packets down the stack, which is expensive. Miller agreed that the lack of monitoring for XDP programs is a large issue that needs to be resolved, and suggested creating a way to mark packets for extraction to allow analysis. Cloudflare is currently in a testing phase with XDP and it is unclear if its whole XDP tool chain will be publicly available. While those two companies are starting to use XDP as-is, there is more work needed to complete the XDP project. As mentioned above and in our previous coverage, massive statistics extraction is still limited in the Linux kernel and introspection is difficult. Furthermore, while the existing actions (XDP_DROP and XDP_TX, see the documentation for more information) are well implemented and used, another action may be introduced, called XDP_REDIRECT, which would allow redirecting packets to different network interfaces. Such an action could also be used to accelerate bridges as packets could be "switched" based on the MAC address table. XDP also requires network driver support, which is currently limited. For example, the Intel drivers still do not support XDP, although that should come pretty soon. Miller, in his Netdev keynote, focused on XDP and presented it as the standard solution that is safe, fast, and usable. He identified the next steps of XDP development to be the addition of debugging mechanisms, better sampling tools for statistics and analysis, and user-space consistency. Miller foresees a future for XDP similar to the popularization of the Arduino chips: a simple set of tools that anyone, not just developers, can use. He gave the example of an Arduino tutorial that he followed where he could just look up a part number and get easy-to-use instructions on how to program it. Similar components should be available for XDP. For this purpose, the conference saw the creation of a new mailing list called xdp-newbies where people can learn how to create XDP build environments and how to write XDP programs.

In-kernel layer-7 proxying The third approach that struck me as innovative is the idea of doing layer-7 (application) proxying directly in the kernel. This comes from the idea that, traditionally, we build firewalls to segregate traffic and apply controls, but as most services move to HTTP, those policies become ineffective. Thomas Graf, presented this idea during Netconf using a Star Wars allegory: what if the Death Star were a server with an API? You would have endpoints like /dock or /comms that would allow you to dock a ship or communicate with the Death Star. Those API endpoints should obviously be public, but then there is this /exhaust-port endpoint that should never be publicly available. In order for a firewall to protect such a system, it must be able to inspect traffic at a higher level than the traditional address-port pairs. Graf presented a design where the kernel would create an in-kernel socket that would negotiate TCP connections on behalf of user space and then be able to apply arbitrary eBPF rules in the kernel. In this scenario, instead of doing the traditional transfer from Netfilter's TPROXY to user space, the kernel directly decapsulates the HTTP traffic and passes it to BPF rules that can make decisions without doing expensive context switches or memory copies in the case of simply wanting to refuse traffic (e.g. issue an HTTP 403 error). This, of course, requires the inclusion of kTLS to process HTTPS connections. HTTP2 support may also prove problematic, as it multiplexes connections and is harder to decapsulate. This design was described as a "pure pre-accept() hook". Starovoitov also compared the design to the kernel connection multiplexer (KCM). Tom Herbert, KCM's author, agreed that it could be extended to support this, but would require some extensions in user space to provide an interface between regular socket-based applications and the KCM layer. In any case, if the application does TLS (and lots of them do), kTLS gets tricky because it breaks the end-to-end nature of TLS, in effect becoming a man in the middle between the client and the application. Eric Dumazet argued that HA-Proxy already does things like this: it uses splice() to avoid copying too much data around, but it still does a context switch to hand over processing to user space, something that could be fixed in the general case. Another similar project that was presented at Netdev is the Tempesta firewall and reverse-proxy. The speaker, Alex Krizhanovsky, explained the Tempesta developers have taken one person month to port the mbed TLS stack to the Linux kernel to allow an in-kernel TLS handshake. Tempesta also implements rate limiting, cookies, and JavaScript challenges to mitigate DDoS attacks. The argument behind the project is that "it's easier to move TLS to the kernel than it is to move the TCP/IP stack to user space". Graf explained that he is familiar with Krizhanovsky's work and he is hoping to collaborate. In effect, the design Graf is working on would serve as a foundation for Krizhanovsky's in-kernel HTTP server (kHTTP). In a private email, Graf explained that:

The main differences in the implementation are currently that we foresee to use BPF for protocol parsing to avoid having to implement every single application protocol natively in the kernel. Tempesta likely sees this less of an issue as they are probably only targeting HTTP/1.1 and HTTP/2 and to some [extent] JavaScript.

Neither project is really ready for production yet. There didn't seem to be any significant pushback from key network developers against the idea, which surprised some people, so it is likely we will see more and more layer-7 intelligence move into the kernel sooner rather than later.

Conclusion All of this work aims at replacing a rag-tag bunch of proprietary solutions that recently came up to bypass the Linux kernel TCP/IP stack and improve performance for firewalls, proxies, and other key edge network elements. The idea is that, unless the kernel improves its performance, or at least provides a way to bypass its more complex code paths, people will work around it. With this set of solutions in place, engineers will now be able to use standard APIs to hook high-performance systems into the Linux kernel.

The author would like to thank the Netdev and Netconf organizers for travel assistance, Thomas Graf for a review of the in-kernel proxying section of this article, and Jesper Dangaard Brouer for review of the af_packet and XDP sections. Note: this article first appeared in the Linux Weekly News.

What happened in the Reproducible Builds effort between April 24th and 30th 2016. Media coverage Reproducible builds were mentioned explicitly in two talks at the Mini-DebConf in Vienna:

• Martin Michlmayr had a talk in which he presented an overview about innovations and changes in Debian in the last years. Martin expressed his disappointment that there was no talk from us in Vienna (we'll fix this at DebConf16 in Cape Town) and described the reproducible builds work as "a real innovation". His talk is very much worth seeing, whatever your current perspective, it might change your view on Debian.
• Ben Hutchings explains how Secure Boot will use signed kernels via separate signature packages and how this was designed with reproducible builds in mind.

Aspiration together with the OTF CommunityLab released their report about the Reproducible Builds summit in December 2015 in Athens. Toolchain fixes Now that the GCC development window has been opened again, the SOURCE_DATE_EPOCH patch by Dhole and Matthias Klose to address the issue timestamps_from_cpp_macros (__DATE__ / __TIME__) has been applied upstream and will be released with GCC 7. Following that Matthias Klose also has uploaded gcc-5/5.3.1-17 and gcc-6/6.1.1-1 to unstable with a backport of that SOURCE_DATE_EPOCH patch. Emmanuel Bourg uploaded maven/3.3.9-4, which uses SOURCE_DATE_EPOCH for the maven.build.timestamp. (SOURCE_DATE_EPOCH specification) Other upstream changes Alexis Bienven e submitted a patch to Sphinx which extends SOURCE_DATE_EPOCH support for copyright years in generated documentation. Packages fixed The following 12 packages have become reproducible due to changes in their build dependencies: hhvm jcsp libfann libflexdock-java libjcommon-java libswingx1-java mobile-atlas-creator not-yet-commons-ssl plexus-utils squareness svnclientadapter The following packages have became reproducible after being fixed:

• anope/2.0.3-2 by Dominic Hargreaves, original patch by Alexis Bienven e.
• apparmor-profiles-extra/1.7 by intrigeri, patch by Felix Geyer.
• basket/2.10~beta+git20160425.b77687f-1 by Luigi Toscano, original patch by Alexis Bienven e.
• bind-dyndb-ldap/8.0-2 by Timo Aaltonen.
• bliss/0.73-1 by Jerome Benoit.
• gap-alnuth/3.0.0-3 by Bill Allombert.
• gap-radiroot/2.7-2 by Bill Allombert.
• genometools/1.5.8+ds-3 by Sascha Steinbiss.
• gprbuild/2015-3 by Nicolas Boulenguez.
• gtkhash/0.7.0-3 by M nica Ram rez Arceda.
• josm/0.0.svn10161+dfsg-1 by Bas Couwenberg.
• libjgoodies-animation-java/1.4.3-1 by Markus Koschany.
• ltrsift/1.0.2-7 by Sascha Steinbiss.
• mutt/1.6.0-1 by Matteo F. Vescovi, original patch by Daniel Shahaf.
• netsniff-ng/0.6.1-1 by Kartik Mistry, original patch by Reiner Herrmann.
• netrw/1.3.2-3 by Giovanni Mascellani.
• openthesaurus/20160424-3 by Rene Engelhard, original patch by Dhole.
• php-pear/1:1.10.1+submodules+notgz-8 by Mathieu Parent.
• samba/2:4.4.2+dfsg-2 by Jelmer Vernoo .
• swift/2.7.0-3 by Ond ej Nov .
• tp-smapi/0.42-1 by Evgeni Golov, original patch by Chris Lamb.
• vifm/0.8.1a-0.1 by Ond ej Nov .
• xfonts-mplus/1:2.2.4-2 by Hideki Yamane, original patch by Chris Lamb.
• xpa/2.1.17-2 by Ole Streicher, original patch by Alexis Bienven e.

Some uploads have fixed some reproducibility issues, but not all of them:

• camitk/4.0.0~beta-1 by Emmanuel Promayon, original patch by Maria Valentina Marin.
• elastix/4.8-8 by Gert Wollny.
• freefem++/3.46+dfsg1-1 by Dimitrios Eftaxiopoulos, original patch by Alexis Bienven e.
• grib-api/1.15.0-1 by Alastair McKinstry, original patch by Santiago Vila.
• isorelax/20041111-9 by Emmanuel Bourg.
• libical/2.0.0-0.1 by Andreas Henriksson, original patch by Chris Lamb.
• sawfish/1:1.11.90-1 by Jose M Calhariz, original patch by Alexis Bienven e.
• singular/4.0.3-p1+ds-1 by Jerome Benoit.
• syslinux/3:6.03+dfsg-12 by Mattia Rizzolo, original patch by Reiner Herrmann.
• transdecoder/2.0.1+dfsg-3 by Michael R. Crusoe, original patch by Dhole.

Patches submitted that have not made their way to the archive yet:

• #822566 against stk by Alexis Bienven e: sort lists of object files for reproducible linking order.
• #822948 against shotwell by Alexis Bienven e: normalize tarball permissions and use locale/timezone-independent modification time.
• #822963 against htop by Alexis Bienven e: use SOURCE_DATE_EPOCH for embedded copyright year, which has before already been applied in git and upstream.

Package reviews 95 reviews have been added, 15 have been updated and 129 have been removed in this week. 22 FTBFS bugs have been reported by Chris Lamb and Martin Michlmayr. diffoscope development

• diffoscope 52~bpo8+1 has been uploaded to jessie-backports by Mattia Rizzolo, where it is currently waiting for NEW-approval.
• Support for the deb(5) format (uncompressed data.tar/control.tar, control.tar.xz) (Closes: #818414) has been completed by Reiner Herrmann in git.

strip-nondeterminism development

• Support for EPUB documents has been added (to the development version in git) by Holger Levsen, to address the timestamps_in_epub issue.

tests.reproducible-builds.org

• To monitor the uptodateness of diffoscope everywhere, tests checking this on FreeBSD, NetBSD & MacPorts were added. Tests on other distributions will be added once the relevant bugs in whohas are fixed in jessie. (h01ger)

Misc. Amongst the 29 interns who will work on Debian through GSoC and Outreachy there are four who will be contributing to Reproducible Builds for Debian and Free Software. We are very glad to welcome ceridwen, Satyam Zode, Scarlett Clark and Valerie Young and look forward to working together with them the coming months (and maybe beyond)! This week's edition was written by Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

What happened in the reproducible builds effort this week: Toolchain fixes

• Emmanuel Bourg uploaded maven-archiver/2.6-3 which fixed parsing DEB_CHANGELOG_DATETIME with non English locales.
• Emmanuel Bourg uploaded maven-repo-helper/1.8.12 which always use the same system independent encoding when transforming the pom files.
• Piotr O arowski uploaded dh-python/2.20150719 which makes the order of the generated maintainer scripts deterministic. Original patch by Chris Lamb.

akira uploaded a new version of doxygen in the experimental reproducible repository incorporating upstream patch for SOURCE_DATE_EPOCH, and now producing timezone independent timestamps. Dhole updated Peter De Wachter's patch on ghostscript to use SOURCE_DATE_EPOCH and use UTC as a timezone. A modified package is now being experimented. Packages fixed The following 14 packages became reproducible due to changes in their build dependencies: bino, cfengine2, fwknop, gnome-software, jnr-constants, libextractor, libgtop2, maven-compiler-plugin, mk-configure, nanoc, octave-splines, octave-symbolic, riece, vdr-plugin-infosatepg. The following packages became reproducible after getting fixed:

• cpl-plugin-fors/5.0.11+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-hawki/1.8.18+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-kmos/1.3.12+dfsg-4 uploaded by Ole Streicher, original patch by Chris Lamb.
• cpl-plugin-visir/3.5.1+dfsg-3 uploaded by Ole Streicher, original patch by Chris Lamb.
• docbook-dsssl/1.79-8 uploaded by Peter Eisentraut, original patch by Chris Lamb.
• git-annex/5.20150617 by Joey Hess, initial report by Daniel Kahn Gillmor.
• links2/2.10-1 by Axel Beckert.
• linuxlogo/5.11-8 uploaded by Dariusz Dwornikowski, original patch by Reiner Herrmann.
• maradns/2.0.11-1 uploaded by Dariusz Dwornikowski, original patch by Reiner Herrmann.
• pkgconf/0.9.12-1 uploaded by Andrew Shadura, original patch by Juan Picca.
• python-odf/1.3.1+dfsg-1 uploaded by W. Martin Borgert, original patch by akira.
• qsapecng/2.0.0-6 uploaded by Simone Rossetto, original patch by akira.
• ruby-liquid/3.0.4-1 uploaded by C dric Boutillier, report by Dylan Thacker-Smith.
• ruby-standalone/0.5.1 uploaded by Antonio Terceiro, original patch by Reiner Herrmann.
• sahara/2015.1.0-6 uploaded by Thomas Goirand, original patch by Juan Picca.
• squid3/3.5.6-1 uploaded by Luigi Gangitano, fixed upstream.
• tabble/0.43-3 uploaded by gregor herrmann, original patch by Reiner Herrmann.
• twine/1.5.0-1 by Zygmunt Krynicki.
• visp/2.10.0-4 uploaded by Fabien Spindler, original patch by akira.

Some uploads fixed some reproducibility issues but not all of them:

• dpatch/2.0.36 by Gergely Nagy, with a patch from akira.
• fldigi/3.22.13-1 by Kamal Mostafa.
• fortunes-bg/1.2 uploaded by Anton Zinoviev, original patch by akira.
• openjfx/8u40-b25-3 by Emmanuel Bourg.
• zoneminder/1.28.1-7 by Dmitry Smirnov.
• zookeeper/3.4.6-5 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #792943 on argus-client by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792945 on authbind by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792947 on cvs-mailcommit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792949 on chimera2 by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792950 on ccze by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792951 on dbview by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792952 on dhcpdump by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792953 on dhcping by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792955 on dput by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792958 on dtaus by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792959 on elida by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792961 on enemies-of-carlotta by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792963 on erc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792965 on fastforward by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792967 on fgetty by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792969 on flowscan by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792971 on junior-doc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792972 on libjama by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792973 on liblip by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792974 on liblockfile by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792975 on libmsv by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792976 on logapp by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792977 on luakit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792978 on nec by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792979 on runit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792980 on tworld by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792981 on wmweather by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792982 on ftpcopy by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792983 on gerstensaft by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792984 on integrit by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792985 on ipsvd by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792986 on uruk by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792987 on jargon by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792988 on xbs by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792989 on freecdb by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792990 on skalibs by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792991 on gpsmanshp by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792993 on cgoban by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792994 on angband-doc by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792995 on abook by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792996 on bcron by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792998 on chiark-utils by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #792999 on console-cyrillic by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793000 on beav by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793001 on blosxom by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793002 on cgilib by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793003 on daemontools by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793004 on debdelta by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793005 on checkpw by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793006 on dropbear by akira: set the mtimes of all files which are modified during builds to the latest debian/changelog entry.
• #793126 on torbutton by Dhole: set TZ=UTC when calling zip.
• #793127 on pdf.js by Dhole: set TZ=UTC when calling zip.
• #793300 on deejayd by Dhole: set TZ=UTC when calling zip.

reproducible.debian.net Packages identified as failing to build from source with no bugs filed and older than 10 days are scheduled more often now (except in experimental). (h01ger) Package reviews 178 obsolete reviews have been removed, 59 added and 122 updated this week. New issue identified this week: random_order_in_ruby_rdoc_indices. 18 new bugs for packages failing to build from sources have been reported by Chris West (Faux), and h01ger.

A new major release of RQuantLib is now on CRAN and getting to Debian. All C++ source files have been rewritten to take advantage of newer Rcpp features. Several Fixed Income functions have been added, or refreshed, thanks to contributions by Michele Salvadore. Calendar support was greatly expanded thanks to a contribution by Danilo Dias da Silva. All key changes are listed in detail below.

Changes in RQuantLib version 0.4.0 (2014-12-01)

• Changes in RQuantLib code:
  • All function interfaces have been rewritten using Rcpp Attributes. No SEXP remain in the function signatures. This make the code shorter, more readable and more easily extensible.
  • The header files have been reorganized so that plugin use is possible. An impl.h files is imported once for each compilation unit: for RQuantLib from the file src/dates.cpp directory, from a sourced file via a #define set by the plugin wrapper.
  • as<>() and wrap() converters have added for QuantLib Date types.
  • Plugin support has been added, allowing more ad-hoc use via Rcpp Attributes.
  • Several Fixed Income functions have been added, and/or rewritten to better match the QuantLib signatures; this was done mostly by Michele Salvadore.
  • Several Date and Calendar functions have been added.
  • Calendar support has been greatly expanded thanks to Danilo Dias da Silva.
  • Exported curve objects are now more parsimonious and advance entries in the table object roughly one business month at a time.
  • The DiscountCurve and Bond curve construction has been fixed via a corrected evaluation date and omitted the two-year swap rate, as suggested by Luigi Ballabio.
  • The NAMESPACE file has a tighter rule for export of *.default functions, as suggested by Bill Dunlap
  • Builds now use OpenMP where available.
  • The package now depends on QuantLib 1.4.0 or later.
• Changes in RQuantLib tests:
  • New unit tests for dates have been added.
  • C++ code for the unit tests has also been converted to Rcpp Attributes use; a helper function unitTestSetup() has been added.
  • Continuous Integration via Travis is now enabled from the GitHub repo.
• Changes in RQuantLib documentation:
  • This NEWS file has been added. Better late than never, as they say.

Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list off the R-Forge page. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Finally I've found time to look back at vacation in Rome and post some pictures. It has been great time there and I've really enjoyed that. I would like to thank to Luigi Gangitano for showing us some interesting places in the city. And now back to pictures:

Filed under: English Photography Travelling 0 comments Flattr this!

For my birthday back in October, my wonderful wife gave me a Kindle 3 from Amazon. I d been considering other e-book readers for quite some time, but I had mostly ignored the Kindle due to the lack of EPUB support and a general dislike of Amazon s DRM enforcement. In the end, the superior hardware and ecosystem of the Kindle overpowered those concerns and overall I m very pleased with the purchase. The screen is amazing, literally just like reading off a piece of paper and the selection of books is OK. I ve been buying almost all my books from Amazon to date since it s so easy (the Whispernet is amazingly quick!) but it s not terribly difficult to get EPUBs from elsewhere onto the device after a quick run through Calibre to turn them into a MOBI file, so I keep telling myself I ve still got some flexibility. Almost as much fun as reading on the device has been learning about how it works. The Mobile Read forums have lots of step by step posts on how to do specific tasks like replacing the screensaver image, but they don t give much background detail on how the Kindle is actually operating which is what really interests me. Luckily among all the step by step posts I also found a usbnetwork package which also adds an SSH server to the Kindle, so after installing that and then SSHing in to my Kindle I ve been poking around. Under the cover the Kindle reveals a fairly standard Linux installation. While the hardware and IO devices are obviously unique, compared to something like an Android phone, the Kindle is refreshingly normal . Hardware

• Freescale MX35 ARMv6 based CPU with Java specific instruction support.
• 256MB RAM
• 4GB of internal flash presented as an SDHC device with four partitions. A ~700MB root partition, a ~30MB /var/local partition, another roughly 30MB kernel partition and then the rest (~3.1G) as the writeable user partition where your books and other content are stored. The root and /var/local partitions are ext3! (not jffs or some other more traditional flash based file system) while the user partition is vfat for easy use with Windows, etc.
• The board is code-named luigi and there are lots of references to mario and fiona scattered around the device, and even in some URLs on Amazon s website. Someone was obviously a Super Mario fan.
• The wireless chipset is Atheros based using the ar6000 drivers.
• The WAN (3G) modem presents itself as a USB serial device and is controlled via a custom daemon named wand which uses the standard Linux pppd package to establish IP connections over a private APN Amazon (provided by Vodafone here in Ireland).
• The EInk display shows up as some special files under /proc rather than as a device. With a bit of digging I found some simple constants that when written to the proc files cause the screen to display the standard boot/progress/upgrading images. I haven t deciphered how to make more complex updates to the display yet.

Software

• The kernel is based on Linux 2.6.26, with a bunch of hardware specific patches and drivers from lab126.com, an Amazon subsidiary who appear to be responsible for much of the low-level driver and device development.
• Lots of familiar open source projects are present, e.g. syslog-ng, DBus, busybox, pppd, wpa_supplicant, gstreamer, pango, openssl and the list goes on. You can download all the sources from Amazon s website. I haven t spent any time to see what if anything has been modified.
• There were a few unexpected finds as well such as GDB and powertop! No doubt useful for the developers, but highly unlikely to actually be used on a shipping Kindle.
• Boot-up is controlled by a set of sysv style init scripts which setup the filesystems and then start a handful of daemons to look after the low-level subsystems (network, power, sound) as well as the standard syslog and cron daemons you d expect to see on any Linux box.
• Once the basic system is up and running the init scripts kick off the framework which lives under /opt/amazon/ebook and consists of lots of Java classes. The system uses the cvm Java environment from Sun/Oracle which is specialised for embedded low-memory devices like this. The framework appears to take over most of the co-ordination, management and interaction tasks once it has started up.

The application/framework code is heavily obfuscated apparently using the Allatori Java Obfuscator. The jrename and jd-gui utilities have proven very handy in helping to untangle the puzzle, although they still only leave you with a pile of Java source code with mostly single letter alphabetic variable and class names! I ve been using IntelliJ s support for refactoring/renaming Java code to slowly work through it (thanks in large part to error/log messages and string constants found through the code which can t be obfuscated easily and help to explain what is going on), and I m slowly beginning to piece together how the book reading functionality works. I ll maybe write more on this in a future post. In one of my initial tweets about the Kindle I mentioned that it seemed to be regularly uploading syslog data to Amazon based on some sendlogs scripts I d noticed and a few syslog lines containing GPS co-ordinates that had been pasted on the Mobile Read forums. I can t find any trace of GPS co-ordinates in any syslog messages I ve seen on my device, but there is definitely information about the cell sites that my Kindle can see, the books that I m opening and where I m up to in them:

101206:235431 wand[2515]: I dtp:diag: t=4cfd77b7,MCC MNC=272 01,Channel=10762,Band=WCDMA I IMT 2000,Cell ID=1362209,LAC=3021,RAC=1
,Network Time=0000/00/00 00.00.00,Local Time Offset=Not provided,Selection Mode=Automatic,Test Mode=0,Bars=4,Roaming=1,RSSI=-88,Tx
Power=6,System Mode=WCDMA,Data Service Mode=HSDPA,Service Status=Service,Reg Status=Success,Call Status=Conversation,MM Attach St
ate=Attach accept,MM LU State=LU update,GMM Attach State=Attach accept,GMM State=Registered,GMM RAU State=Not available,PDP State=
Active,Network Mode=CS PS separate attach mode,PMM Mode=Connected,SIM Status=Valid; PIN okay; R3,MM Attach Error=No error,MM LU Er
ror=No error,GMM Attach Error=No error,GMM RAU Error=Not available,PDP Rej Reason=No error,Active/Monitored Sets=0;39;-11 1;180;-1
5,RSCP=-111,DRX=64,HSDPA Status=Active,HSDPA Indication=HSDPA HSUPA unsupp,Neighbor Cells=,Best 6 Cells=,Pathloss=,MFRM=,EGPRS Ind
ication=,HPLMN=,RPLMN=272;01 ,FPLMN=234;33 234;30 234;20 272;05 ,n=1: 101206:235758 cvm[3426]: I Reader:BOOK INFO:book asin=B003IWZZ3Y,file size=233168,file last mod date=2010-11-27 19.18.22 +0000,con
tent type=ebook,length=MobiPosition_ 465747,access=2010-12-06 09.44.32 +0000,last read position=MobiPosition_ 464387,isEncrypted=f
alse,isSample=false,isNew=false,isTTSMetdataPresent=false,isTTSMetadataAllowed=true,fileExtn=azw: 101206:233416 udhcpc[5639]: Offer from server xxx.xxx.2.254 received
101206:233416 udhcpc[5639]: Sending select for xxx.xxx.2.10...
Interestingly you can see from the last two lines, that Amazon has taken some care to preserve privacy by not including the full IP address given to the device by my local Wifi network, so in light of that I find it interesting that they decided not to obfuscate the Cell and Book IDs in those respective log messages too. Seems rather inconsistent. As to how and when these logs are sent to Amazon, the picture is a little bit murky. Every 15 minutes tinyrot runs out of cron and rotates /var/log/messages if it is greater than 256k in size. Rotated logs are stored into /var/local/log under filenames like messages_00000044_20101207000006.gz and alongside the log files are a set of state files named nexttosendfile, messages_oldest, messages_youngest. Something regularly sweeps through this directory to update the state and remove the old logs (after sending them up to Amazon I assume). I suspect that something is buried in the Java application code mentioned above. On the whole the Kindle is a fascinating piece of technology. It delivers a wonderful reading experience on top of a familiar Linux system and is going to provide me with many more hours of entertainment as I unpack all the tricks and techniques that have gone into this device. I would recommended it as a present for geeks everywhere.

There is a drupal6 package in Debian, but for me as a Drupal User its support in Debian is somewhat unsatisfactory. Apparently it's not just me, but several other users are in the same situation. Drupal releases new version when a security issue was fixed in Drupal Core. Currently there are several security issues pending that are fixed in newer upstream version 6.15, which was releases on 2009-12-16. Bug #561726 deals with this as well as #562165.
It seems as if the maintainer is busy with other things, which is fairly ok, and if he isn't following Drupal security mailing list as we, as the users, are always need to forward and remember him about the security updates. Not just now, but also in the past. Remembering the maintainer about security updates is ok for me, alas it's somewhat tedious doing so. And beside the current situation, which made be ok giving Christmas vacation, Happy New Year and such, I'm quite satisfied with the work of the maintainer. But: could someone else please upload a new version of Debian in the meanwhile, please?! ;-)

UPDATE:
Luigi uploaded drupal 6.15 to unstable and I'm subscribed to pkg-drupal-devel on Alioth... ;)

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära

Desde su concepci n, Planeta Linux ha exhortado a sus participantes a sindicar contenido exclusivamente relacionado con tecnolog a, computaci n, software libre y Linux, en orden incremental de preferencia. Pronto se determin que la exhortaci n no era suficiente y se pas al requerimiento. H ctor Colina y Milton Mazzarri, por nombrar dos venezolanos, estuvieron involucrados en los Lineamientos y las Preguntas Frecuentes de Planeta Linux Venezuela. Como para ese momento ya hab amos hecho un grupo inicial de “venezolanos con blog que hablan de Linux” (b sicamente gente de VELUG, SOLVE, Debian Venezuela y de unplug.org.ve), no tuvimos la oportunidad de requerirles que tuvieran una categor a dedicada a Planeta Linux. A las nuevas personas que se inscrib an por la lista, en ocasiones se les requer a la categor a si su blog conten a, a primera vista, contenido no relacionado con Linux. En todos los casos, se requer a estar de acuerdo con los Lineamientos. En el caso de las personas que me solicitaban a mi directamente (que desde hace no mucho tengo acceso al SVN de Planeta Linux) yo les requer a una categor a particular, a menos de que su software no lo permitiera. En este ltimo caso, muy a pesar de los quejones de oficio, elimin bamos a la persona de PL. Es el caso de Luigino Bracci, quien en alguna ocasi n lleg a llenar todo Planeta Linux con contenido pol tico parcializado, y quien manifest que su sistema de blogs no le permit a agregar categor as. Hay casos en los que una persona que escribe poco o que suele escribir de Linux llega y hace algun desastre al estilo Alberto Capella con su foto a tama o gigante. En esos casos alguien se da cuenta y me avisa (aunque es un error, al final de la p gina hay direcciones de contacto y en Venezuela somos varios que administramos!) pero estoy involucrado en muchas cosas como para dar respuesta inmediata a ese tipo de casos. Y ah viene otro problema. En Planeta Linux NO PODEMOS moderar un post o a una persona. Solo podemos suspenderlo o eliminarlo. No podemos borrar una imagen ni un post ni nada, porque en 15 minutos perdemos los cambios. Espero que eso de algunas luces cuando haya algo de que quejarse en Planeta Linux. El ltimo caso es particular. Jes s Lara hizo varios posts no relacionados con Linux en su blog. Particularmente hubo gente que reclam que hab an recien escrito algo relacionado con Linux y los posts de Jes s “empujaron” los posts relacionados con Linux hacia el final del Planeta. Por lo tanto suspendi la suscripci n de Jes s y lo contact el 9 de Abril. Cre una categor a y me lo comunic . Eso es suficiente para volver a reactivar su suscripci n (en este caso me tard unos d as porque el commit fall y nunca me enter de ello, ni Jes s me lo inform , realmente) Ya hay mucha gente que sindica categor as en PL, y pronto ser n muchos m s. Cont ctenme si quieren hacer el proceso pronto. Por favor, la pr xima vez que encuentren un problema en Planeta Linux:

• Av sennos a Milton Mazzarri, David Moreno Garza o a mi, o a trav s de los medios de contacto de Planeta Linux. Podemos ayudarles, y el trabajo voluntario no nos excluye de responsabilidades.
• Den ideas y soluciones, que son muy bien recibidas. No den cr ticas ni flameen, porque recibir n lo mismo de vuelta (aqu son bienvenidos todos los que usen Linux en Venezuela, no traigan los vicios de los grupos de usuarios y las listas de amor y dolor)
• Descarten la teor a de la conspiraci n. No todos los que est n involucrados en proyectos comunitarios de Software Libre tienen problemas de cari o ni necesitan pensar que otros los atacan o necesitan meterse en la vida de los dem s. Lo m s probable es que lo hayamos olvidado o no tengamos tiempo. Usen el sentido com n.

Leon Brooks linked to this article claiming that sound not electricity travels through nerves.

When you put a moderate voltage through your body it will cause muscle action (try putting 1000V at low current between fingers of the same hand for safety). The original experiment that suggested that electricity is used involved applying a shock to the legs of a dead frog (see the Wikipedia entry for Luigi Galvani).

For this claim about sound to be valid the electric shocks would have to cause sound in the nervous system. Also sound impulses would have to trigger nerve action (IE the "brown note"). AFAIK neither of these have been proven.