Today I was idly performing some maintainence upon one of my hosts, and it crossed my mind to look beneath /etc in there I found:

/etc/python
/etc/python2.4
/etc/python2.5
/etc/python2.6

That made me look more closely at the contents of /etc - the following command output was surprising:

steve@steve:~$ ls /etc   wc -l
187

Is that average? Heavy? Light? I have no idea, but I purged a hell of a lot of software today. Now I have only python v2.6 although for some reason I still have:

python
python-apt
python-apt-common
python-central
python-minimal
python-support
python2.6
python2.6-minimal

I suspect I could drop the pything2.6-minimal package, but for the moment I'm done. I have to make pretty people look exceptional with my magical camera. Anyway as part of this cleanup I ran a quick sanity-check on which processes are running and I think, short of kernel processes, I'm as minimal as I can be. I understand the purpose and reason for every running service:

UID        PID  CMD
root         1  init [2]
pdnsd    14091  /usr/sbin/pdnsd --daemon -p /var/run/pdnsd.pid
root     14199  /usr/sbin/monit -c /etc/monit/monitrc -s /var/lib/monit/monit.state
root     14206  /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
root     14234  /usr/sbin/cron
102      14595  /usr/sbin/exim4 -bd -q30m
redis    14627  /usr/bin/redis-server /etc/redis/redis.conf
root     14637  /usr/sbin/sshd

These are basic services; I use monit to ensure those essential daemons keep running. The only oddity there is probably the local DNS cache, but it is useful if you run any kind of DNS blacklist-using service, for example.

root     14794  /sbin/getty -L ttyS0 9600 vt100

I need a serial console login for emergencies.

root     14796  runsv node-reverse-proxy
root     14797  /bin/sh ./run
root     14799  /opt/node/bin/node node-reverse-proxy.js --config ./rewrites.js

These three processes combine to run my reverse proxy which routes incoming HTTP requests to a number of local thttpd instances.

qpsmtpd  27309    /usr/bin/perl -Tw /usr/bin/qpsmtpd-prefork --port 25 --user qpsmtpd --pid-file /var/run/qpsmtpd/qpsmtpd.pid --detach
..

The perl SMTP daemon which runs my incoming mail, passing it to exim4 which listens upon 127.0.0.1:2525. You can read about my setup in the out-of-date writeup Chris & I put together.

 /usr/bin/memcached -m 64 -p 11211 -u root -l 127.0.0.1

Memory cache for transient items.

s-blog    thttpd -C /etc/thttpd/sites.enabled/blog.steve.org.uk
1030      thttpd -C /etc/thttpd/sites.enabled/edinburgh-portraits.com
s-hg      thttpd -C /etc/thttpd/sites.enabled/hg.steve.org.uk
s-ipv4    thttpd -C /etc/thttpd/sites.enabled/ipv4.steve.org.uk
s-ipv6    thttpd -C /etc/thttpd/sites.enabled/ipv6.steve.org.uk
s-kvm     thttpd -C /etc/thttpd/sites.enabled/kvm-hosting.org
...

One thttpd instance is launched for each distinct HTTP site my server runs. Each site runs under its own UID, with its own chrooted directory tree. This is important for security. Each local instance listens upon 127.0.0.1 - and the reverse proxy previously mentioned rewrites connections to the appropriate one.

1016     28812     /usr/bin/perl -I./lib/ -I./ /usr/local/bin/blogspam

My anti-spam filter for blog comments.

Here is my christmas challenge. Can you identify each service upon your host? Do you know why you're running what you're running? Me? I had no idea I had a dbus deamon running. Now I've purged it. Ha! ObQuote - "I owe everything to George Bailey. Help him, dear Father." - It's a wonderful life.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (310.73 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg: Multi-Arch Saga I know lots of people are waiting the landing of multiarch in Debian unstable, and so am I. Things are progressing, though not as quickly as I hoped. Guillem merged about half of the branch between the 24th October and the 6th of November. After that most of the work happened on his personal repository in his pu/multiarch/master branch. I verify this repository from time to time because Guillem does not inform me when he has made progress. I noticed changes on his repository on the 10th, 19th, 23th, 28th of November and on the 1th of December. He announced a long time ago that he had some interface changes and up to now only wrote about the switch from the command-line option --foreign-architecture (to put in /etc/dpkg/dpkg.cfg) to the explicit command dpkg --add-architecture that only needs to be called once (see mail here). As of today (December 2th), the promised email for the other interface changes is still not here. On November 23th, I reviewed Guillem s work and tried to run the code in his branch. I spent the whole day chasing up regressions and submitted lots of fixes to Guillem. Thanks to the extensive test-suite I wrote when I developed my branch, it has been fairly easy to track them all down. All the issues I reported have been fixed in the latest version of Guillem s branch although the fixes are often slightly different from those that I submitted. Dpkg: Squeeze Backport At the start of the month, I uploaded what I expected to be a fairly uncontroversial backport of dpkg 1.16.1.1. It turns out I was wrong. After some discussion, I think we came to an agreement that it was acceptable to backport dpkg-dev and libdpkg-perl only. My goal was not to bring the latest dpkg to users but to make it easier for package maintainers to backport packages using new features provided by dpkg-dev >= 1.16 (such as hardening build flags, the makefile snippets provided in /usr/share/dpkg/, or the improved dpkg-buildflags interface). Thus I modified the source package uploaded to squeeze-backports to build only dpkg-dev and libdpkg-perl. It has been uploaded on November 23th and it s waiting in the NEW queue for a backports admin to process it. Misc Dpkg Work I merged a patch of Colin Watson to be able to verify build-dependencies for a foreign architecture (taking into account the Multi-Arch status of each package listed). I released dpkg 1.16.1.2 with two minor fixes that were sitting in the sid branch. I wanted to get rid of this so that the path is clear for a 1.16.2 upload with multiarch. The package just migrated to testing so we re fine. I spent another day doing dpkg bug triaging on Launchpad, we re now down to 77 bugs with many of them tagged as incomplete and likely to expire in 2 months. The Debian Administrator s Handbook We released a sample chapter so that it s easier to have an idea of the quality of the book. The chapter covers the APT tools quite extensively. I bet that even you could learn something about apt-get/aptitude The crowfunding campaign on Ulule ended on November 28th.
With 675 supporters, we raised 24385 EUR. Of those, 14935 EUR have been put in the liberation fund and the rest corresponds to the various pre-orders and rewards offered. This means that the translation will happen (we just started) but that the book is currently not going to be released under a free license. Don t despair As planned, the liberation campaign is carried on until the 25 K target is reached! Instead of being hosted on Ulule, this permanent campaign is on the project website at debian-handbook.info/liberation/. Note that any contribution of 10 EUR or more means that you get a copy of the ebook as soon as it s available (even if the liberation target is not reached). Package Tracking System At the start of the month, I filed two ideas of improvements for the PTS in the bug tracking system: #647258 is about showing outstanding bugs that relate to a release goal and #647901 is about warning maintainers that the package is affected by a current transition. If you re a coder and want to start contributing to Debian and its QA team, those bugs could be interesting targets for a start. In both cases, I have been in contact with members of the release team because those ideas require some structured data from the release team as input. Thanks to Meddi Dohguy and Niels Thykier for their help. Later in the month, the topic of relocating the PTS once again came up. For historical reasons, the PTS was hosted on master.debian.org together with the BTS. Nowadays the BTS has its own host and it made no sense anymore to have the PTS separate from the rest of the QA services hosted on qa.debian.org (currently quantz.debian.org). So together with Martin Zobel Helas we took care to plan the migration and on November 19th we executed the plan. It worked like a charm and almost nobody noticed (only one undocumented dependency was missed, which broke the SOAP interface). Misc Packaging Work WordPress was broken in Ubuntu and it was also not properly synchronized with Debian due to an almost useless change on their side. Thus I requested a sync so that the working version from Debian gets imported in Ubuntu. I sponsored the docbook-xsl 1.76.1 upload that I needed for Publican. Then I updated Publican just to discover that the test-suite triggers a new bug in fop (filed as #649476). I disabled the test-suite temporarily and uploaded Publican 2.8 to unstable. BTW, I also filed 2 upstream bugs with patches for issues I discovered while trying to generate the sample chapter of my book (see here and here). I uploaded a version 0.7.1 of nautilus-dropbox and fixed #648215 at the same time. I made an NMU of bison to fix a long-standing release critical bug that hit me once more during an upgrade (see #645038). I uploaded to experimental a new version of gnome-shell-timer compatible with GNOME 3.2. I took the opportunity to install from experimental the few GNOME 3.2 packages which are not yet in unstable Thanks See you next month for a new summary of my activities.

7 comments Liked this article? Click here. My blog is Flattr-enabled.

A few months ago, I had blogged about using R inside of Qt. This used our RInside package for embedding the statistical programming environment and language R inside of a C++ application, and further relies on our Rcpp package for R and C++ integration and object mapping. The example was simple yet powerful: a reimplementation of the standard GUI application of a standard density estimate. Here the user can pick a kernel density function from a selection, and also slide a bandwidth parameter. One nice addition was an entry field already populated with a simple expression for a mixture of Normals, allowing for arbitrary random distributions over which to estimate. The example is pretty (thanks to Qt), and was added to RInside with the last CRAN release 0.2.4. The blog post has a nice screenshot. I had long wondered how to do something similar 'on the web'. Web integration and application frameworks are of course a dime a dozen: Just about any language offers this, with more or less ease. But I wanted something simple yet powerful and fast. And I did not like the idea of a multi-tier app, or of a multi-language mix. I remember having seen something about a web-application framework not unlike Qt, and studying the very useful Wikipedia web application framework comparison I re-discovered Wt (pronounced "Witty"). So there it is, using C++ which brings us ample performance, the ability to connect to a number of libraries and applications (which is important in my quantitatively-minded workd) and avoid the whole multi-tier, multi-language combination. The Wt website has a few more good reason why this may be a suitable idea; the toolkit also offers a very decent amount of features and is amply documented with a fair number of examples. And after just a little bit poking around during two weekends, I now have the following webapp committed in the SVN repository of RInside, and it is all implemented in in less than two hundred (generously commented) lines of code. It is currently up and running at the address shown in the screenshot, so give it a go (though I may take it down at another point in time). I quite like it: The application is responsive: changes in the radio buttons (for the density), or the bandwidth, each trigger reestimation of the density, and a new and updated chart is displayed immediately with no noticeable delay---just like the desktop application did. Best of all, the code logic is essentially unchanged from the Qt-based app. Signals and slots related events to actions, the layout is in terms of standard GUI boxen and containers. And best of all, I did not have to write a line of html, javascript, css or ajax: it is all handled by the Wt toolkit. I was able to drive the app from an Android phone, my tablet, various computers around the house, and had a few friends poke a stick at it from afar. There is at one open issue. Wt launches new instances of the application object with each connection, which is a very clean model. That doesn't map perfectly with R (which is single-threaded) and RInside (which runs as a singleton for the same reason). So right now, each action sends its state back to the client. In other words, each clients own its parameters and well as vector of random numbers. Each new action sends these back to the app which passes it to R, launches the re-estimation and gets an updated chart back which is then shown by the the client. That is not perfect, and maybe a forking model as used by Simon's RServe would be better, though it would require a rewrite of RInside. Not sure if we get there anytime soon. And for simple applications not facing legions of concurrent users, the singleton should still work. It's a proof of concept at this point. Feedback welcome, and RInside and Rcpp questions should go to the rcpp-devel list as usual.

Forbes has an interesting article about crowd-sourcing by criminals and law enforcement [1]. Ulissescastr0 made a Youtube video showing how to install SE Linux on Debian/Etch [2]. Probably no-one is using Etch nowadays so this video is outdated, but it s a good way of teaching people. It would be good if someone made a similar video showing how to do SE Linux things on Squeeze. I discovered the above SE Linux video through Explow which provides a neat interface to multiple searches and information sources [3]. I don t think I will be using Explow much in future as I could get the same result through Google video search. They also have a news portal but there are other sites for that. But it does seem that Explow would be useful for newbies. Eric Michael Johnson wrote an interesting article about the inherent bias in Psychological research based in the US [4]. People who live in urban environments think differently in some ways to people who live in different environments or who have different lifestyles. Therefore generalising from university students in the US to the entire human race is likely to get incorrect results. This is something to consider the next time you are tempted to generalise to the wider population from your own friends, colleagues, etc. The Daily Kos has a scary article about the TSA having a woman detained for reciting part of the US constitution [5]. The US will remain on my list of countries to avoid for the forseeable future. Vorlon has written an informative article about the use of hardening options when building Debian packages [6]. It s now even easier to do this, so every package that simultaneously deals with data of differing levels of integrity or sensitivity should be built this way. Bunker Roy gave an interesting TED talk about his Barefoot College that teaches useful skills to people in rural parts of India who don t have a traditional school education [7]. His talk really shows up some of the arrogance in the people who run traditional education. Justin Hall-Tipping gave an interesting TED talk about ways of solving the world energy problems [8]. He started with explaining the problems and why they need to be urgently solved and then described in detail some of the research that his group has done to solve the problems. This includes flexible photo-voltaic cells, infra-red vision to save on lighting, and a way of using carbon nano-tubes to control the thermal properties of windows.

• [1] http://www.forbes.com/sites/oreillymedia/2011/10/03/the-rise-of-crime-sourcing/
• [2] http://www.youtube.com/watch?v=FLPx7HLLteI
• [3] http://explow.com
• [4] http://blogs.plos.org/blog/2010/09/23/reflections-on-the-weird-evolution-of-human-psychology/
• [5] http://www.dailykos.com/story/2011/10/18/1027775/-TSA-Arrests-Me-for-Using-the-Fourth-Amendment-as-a-Weapon-(Tales-from-the-Edge-of-a-Revolution-2)?via=siderec
• [6] http://web.dodds.net/~vorlon/wiki/blog/Debian:_not_stale_just_hardened/
• [7] http://www.ted.com/talks/bunker_roy.html
• [8] http://www.ted.com/talks/justin_hall_tipping_freeing_energy_from_the_grid.html

If you want to copy debian-installer for System z onto a z/VM user's CMS disk, you don't need access to FTP (and hence the host's TCP/IP stack). You can just use x3270 and transfer files with it. For odd reasons I forgot about this, so let's document it here:

• Figure out which CMS disk is actually writeable for you (most likely the A disk) by issuing Q DISK and looking for "R/W" in the STAT column.
• Select File, File Transfer.
• Tick "Send to host" and "Host is VM/CMS".
• Download the four installer files to your local machine: debian.exec (a startup script that punches the kernel, boot parameters and initrd onto cards and executes the card deck), kernel.debian, parmfile.debian (the boot parameters) and initrd.debian.
• Transfer debian.exec and parmfile.debian with "Transfer ASCII file" ticked and Record Format set to "Variable" ("Add/remove CR at end of line" and "Remap ASCII characters" should both be ticked by default; LRECL and BLKSIZE should both be empty.) The host filename is the CMS filename, so something like "DEBIAN EXEC A" (with the spaces, and A replaces with the letter of the writeable disk of your choice). Both files must be prefectly readable in XEDIT (i.e. properly converted to EBCDIC).
• Then transfer kernel.debian and initrd.debian with "Transfer binary file" ticked and Record Format set to "Fixed" with LRECL = 80. This may take a while.
• Boot up the installer by issuing DEBIAN to z/VM, starting the script. If you needed to rename the files above (the drive letter doesn't matter), you need to adjust DEBIAN EXEC first.
• You should see Linux kernel messages now. Profit.

My current running Xorg server, built with -O0 -g3 -ggdb, having been through a few suspend cycles, hosting a full GNOME Shell session with several billion tabs in a long-running Chromium instance, a couple of terminals, and a freshly-opened gedit, is currently sitting at 20MB resident memory usage, of which 11MB is shared. The freshly-opened gedit instance has 25MB resident, of which 17MB is shared. Bloat is in the eye of the beholder, I guess.

(Those numbers are RES/SHR respectively in top. Correct me if I'm wrong about what they mean.)

For a while now my fellow Collaboran Joone Hur has been working on implementing the Accelerated Compositing infrastructure available in WebKit in webkit-clutter, so that we can use Clutter s powers for compositing separate layers and perform animations. This work is being done by Collabora and is sponsored by BOSCH, whom I d like to thank! What does all this mean, you ask? Let me tell me a bit about it. The way animations usually work in WebKit is by repainting parts of the page every few milliseconds. What that means in technical terms is that an area of the page gets invalidated, and since the whole page is one big image, all of the pieces that are in that part of the page have to be repainted: the background, any divs, images, text that are at that part of the page. What the accelerated compositing code paths allow is the creation of separate pieces to represent some of the layers, allowing the composition to happen on the GPU, removing the need to perform lots of cairo paint operations per second in many cases. So if we have a semi-transparent video moving around the page, we can have that video be a separate texture that is layered on top of the page, made transparent and animated by the GPU. In webkit-clutter s case this is done by having separate actors for each of the layers. I have been looking at this code on and off, and recently joined Joone in the implementation of some of the pieces. The accelerated compositing infrastructure was originally built by Apple and is, for that reason, works in a way that is very similar to Core Animation. The code is still a bit over the place as we work on figuring out how to best translate the concepts into clutter concepts and there are several bugs, but some cool demos are already possible! Bellow you have one of the CSS3 demos that were made by Apple to demo this new functionality running on our MxLauncher test browser. <video controls="controls" src="http://cafe.minaslivre.org/~kov/webkit/ac.webm" width="640"></video> You can also see that the non-Accelerated version is unable to represent the 3D space correctly. Also, can you guess which of the two MxLauncher instances is spending less CPU? In this second video I show the debug borders being painted around the actors that were created to represent layers. <video controls="controls" src="http://cafe.minaslivre.org/~kov/webkit/debug-borders.webm" width="640"></video> The code, should you like to peek or test is available in the ac2 branch of our webkit-clutter repository: http://gitorious.org/webkit-clutter/webkit-clutter/commits/ac2 We still have plenty of work to do, so expect to hear more about it. During our annual hackfest in A Coru a we plan to discuss how this work could be integrated also in the WebKitGTK+ port, perhaps by taking advantage of clutter-gtk, which would benefit both ports, by sharing code and maintenance, and providing this great functionality to Epiphany users. Stay tuned!

Once the private key of some HTTPS web site is compromised, an attacker is able to build a man-in-the-middle attack to intercept and decrypt any communication with the web site. The first step against such an attack is the revocation of the associated certificate through a CRL or a protocol like OCSP. Unfortunately, the attacker could also have recorded past communications protected by this private key and therefore decrypt them. Forward secrecy allows today information to be kept secret even if the private key is compromised in the future. Achieving this property is usually costly and therefore, most web servers do not enable it on purpose. Google recently announced support of forward secrecy on their HTTPS sites. Adam Langley wrote a post with more details on what was achieved to increase efficiency of such a mechanism: with a few fellow people, he wrote an efficient implementation of some elliptic curve cryptography for OpenSSL.

Without forward secrecy To understand the problem when forward secrecy is absent, let s look at the classic TLS handshake when using a cipher suite like AES128-SHA. During this handshake, the server will present its certificate and both the client and the server will agree on a master secret. This secret is built from a 48byte premaster secret generated and encrypted by the client with the public key of the server. It is then sent in a Client Key Exchange message to the server during the third step of the TLS handshake. The master secret is derived from this premaster secret and random values sent in clear-text with Client Hello and Server Hello messages. This scheme is secure as long as only the server is able to decrypt the premaster secret (with its private key) sent by the client. Let s suppose that an attacker records all exchanges between the server and clients during a year. Two years later, the server is decommissioned and sent for recycling. The attacker is able to recover the hard drive with the private key. She can now decrypt any session she recorded: the encrypted premaster secret sent by a client is decrypted with the private key and the master secret is derived from it. The attacker can now recover passwords and other sensitive information that can still be valuable today. The main problem lies in the fact that the private key is used for two purposes: authentication of the server and encryption of a shared secret. Authentication only matters while the communication is established, but encryption is expected to last for years.

Diffie-Hellman with discrete logarithm One way to solve the problem is to keep using the private key for authentication but uses an independent mechanism to agree on a shared secret. Hopefully, there exists a well-known protocol for this: the Diffie-Hellman key exchange. It is a method of exchanging keys without any prior knowledge. Here is how it works in TLS:

1. The server needs to generate once (for example, with openssl dhparam command):
   • p , a large prime number,
   • g , a primitive root modulo p (for every integer a coprime to p , there exists an integer k such that g^k=a\mod p ).
2. The server picks a random integer a and compute g^a \mod p . After sending its regular Certificate message, it will also send a Server Key Exchange message (not included in the handshake depicted above) containing, unencrypted but signed with its private key for authentication purpose:
   • random value from the Client Hello message,
   • random value from the Server Hello message,
   • p , g ,
   • g^a\mod p=A .
3. The client checks that the signature is correct. It also picks a random integer b and sends g^b \mod p=B in a Client Key Exchange message. It will also compute A^b\mod p=g^ ab \mod p which is the premaster secret from which the master secret is derived.
4. The server will receive B and compute B^a\mod p=g^ ab \mod p which is the same premaster secret known by the client.

Again, the private key is only used for authentication purpose. An eavesdropper will only know p , g , g^a\mod p and g^b\mod p . Computing g^ ab \mod p from those values is the discrete logarithm problem for which there is no known efficient solution. Because the Diffie-Hellman exchange described above always uses new random values a and b , it is called Ephemeral Diffie-Hellman (EDH or DHE). Cipher suites like DHE-RSA-AES128-SHA use this protocol to achieve perfect forward secrecy¹. To achieve a good level of security, parameters of the same size as the key are usually used (the security provided by the discrete logarithm problem is about the same as the security provided by factorisation of two large prime numbers) and therefore, the exponentiation operations are pretty slow as we can see in the benchmark below:

Diffie-Hellman with elliptic curves Fortunately, there exists another way to achieve a Diffie-Hellman key exchange with the help of elliptic curve cryptography which is based on the algebraic structure of elliptic curves over finite fields. To get some background on this, be sure to check first Wikipedia article on elliptic curves. Elliptic curve cryptography allows one to achieve the same level of security than RSA with smaller keys. For example, a 224bit elliptic curve is believed to be as secure as a 2048bit RSA key.

Some theory Diffie-Hellman key exchange described above can easily be translated to elliptic curves. Instead of defining p and g , you get some elliptic curve, y^2=x^3+\alpha x+\beta , a prime p and a base point G . All those parameters are public. In fact, while they can be generated by the server, this is a difficult operation and they are usually chosen among a set of published ones. The use of elliptic curves is an extension of TLS described in RFC 4492. Unlike with the classic Diffie-Hellman key exchange, the client and the server need to agree on the various paremeters. Most of this agreement is done inside Client Hello and Server Hello messages. While it is possible to define some arbitrary parameters, web browsers will only support a handful of predefined curves, usually NIST P-256, P-384 and P-521. From here, the key exchange with elliptic curves is pretty similar to the classic Diffie-Hellman one:

1. The server picks a random integer a and compute aG which will be sent, unencrypted but signed with its private key for authentication purpose, in a Server Key Exchange message.
2. The client checks that the signature is correct. It also picks a random integer b and sends bG in a Client Key Exchange message. It will also compute b\cdot aG=abG which is the premaster secret from which the master secret is derived.
3. The server will receive bG and compute a\cdot bG=abG which is the same premaster secret known by the client.

An eavesdropper will only see aG and bG and won t be able to compute efficiently abG . Using ECDHE-RSA-AES128-SHA cipher suite (with P-256 for example) is already a huge speed improvement over DHE-RSA-AES128-SHA thanks to the reduced size of the various parameters involved. Web browsers only support a handful of well-defined elliptic curves, chosen to ease an efficient implementation. Bodo M ller, Emilia K sper and Adam Langley have provided 64bit optimized versions of NIST P-224, P-256 and P-521 for OpenSSL. To get even more details on the matter, you can read the end of the introduction on elliptic curves from Adam Langley, then a short paper from Emilia K sper which presents a 64bit optimized implementation of the NIST elliptic curve NIST P-224.

In practice First, keep in mind that elliptic curve cryptography is not supported by all browsers. Recent versions of Firefox and Chrome should handle NIST P-256, P-384 and P-521 but for most versions Internet Explorer, you are currently out of luck. Therefore, you need to keep accepting other cipher suites. You need a recent version of OpenSSL. Support for ECDHE cipher suites has been added in OpenSSL 1.0.0. Check with openssl ciphers ECDH that your version supports them. If you want to use the 64bit optimized version, you need to run a snapshot of OpenSSL 1.0.1, configured with enable-ec_nistp_64_gcc_128 option. A recent GCC is also required in this case. Next, you need to choose the appropriate cipher suites. If forward secrecy is an option for you, you can opt for ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA cipher suites which should be compatible with most browsers. If you really need forward secrecy, you may opt for ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:EDH-DSS-DES-CBC3-SHA instead. Then, you need to ensure the order of cipher suites is respected. On nginx, this is done with ssl_prefer_server_ciphers on. On Apache, this is SSLHonorCipherOrder on. UPDATED: You need to check ECDHE support for your web server. For nginx, the support has been added in 1.0.6 and 1.1.0. The curve selected defaults to NIST P-256. You can specify another one with ssl_ecdh_curve directive. For Apache, it has been added in 2.3.3 and does not exist in the current stable branch. Adding support for ECDHE is quite easy. You can check how I added it in stud. This issue also exists for DHE cipher suites, in which case you also might have to specify DH parameters to use (generated with openssl dhparam) using some special directive or by appending the parameters to the certificate. Check Immerda Techblog article for more background about this point. The implementation of TLS session tickets may be incompatible with forward secrecy, depending on how they are implemented. When they are protected by a random key generated at the start of the server, the same key could be used for months. Some implementations² may derive the key from the private key. In this case, forward secrecy is broken. If forward secrecy is a requirement for you, you need to either disable tickets or ensure that key rotation happens often. Check with openssl s_client -tls1 -cipher ECDH -connect 127.0.0.1:443 that everything works as expected.

Some benchmarks With the help of the micro-benchmark tool that I developed for my previous article, we can compare the efficiency of cipher suites providing forward secrecy: I have used a snapshot of OpenSSL 1.0.1 (2011/11/25). The optimized version of ECDHE is the one you get by using enable-ec_nistp_64_gcc_128 option when configuring OpenSSL. Let s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15%. The overhead is only per full TLS handshake. If 3 out of 4 of your handshakes are resumed, you need to adjust the numbers. Your mileage may vary but the computational cost for enabling perfect forward secrecy with an ECDHE cipher suite seems a small sacrifice for better security.

---

1. Perfect forward secrecy is an enhanced version of forward secrecy. It assumes each exchanged key are independent and therefore a compromised key cannot be used to compromise another one.
2. For example, this is the case of the implementation I have proposed for stud to enable sharing of tickets between multiple hosts.

I got home from work tonight and zfs had reported that one of the disks in my main pool was dying. no great problem. insert a disk i had spare, and run zpool replace like so:

ganesh:~# zpool replace -f export  scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036 scsi-SATA_ST31000528AS_9VP16X03

and now it s just a matter of waiting until the data has resilvered and i can remove the old dying drive.

ganesh:~# zpool status export -v
  pool: export
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scan: resilver in progress since Mon Nov 28 19:25:49 2011
    75.1G scanned out of 2.29T at 88.3M/s, 7h17m to go
    18.0G resilvered, 3.21% done
config:
        NAME                                                   STATE     READ WRITE CKSUM
        export                                                 ONLINE       0     0     0
          raidz1-0                                             ONLINE       0     0     0
            scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2114122          ONLINE       0     0     0
            scsi-SATA_WDC_WD10EACS-00_WD-WCASJ2195141          ONLINE       0     0     0
            scsi-SATA_WDC_WD10EARS-00_WD-WMAV50817803          ONLINE       0     0     0
            replacing-3                                        ONLINE       0     0     0
              scsi-SATA_WDC_WD10EARS-00_WD-WMAV50933036        ONLINE       0     0     0
              scsi-SATA_ST31000528AS_9VP16X03                  ONLINE       0     0     0  (resilvering)
        logs
          scsi-SATA_Patriot_Torqx_278BF0715010800025492-part6  ONLINE       0     0     0
        cache
          scsi-SATA_Patriot_Torqx_278BF0715010800025492-part7  ONLINE       0     0     0
errors: No known data errors

(I use /dev/disk/by-id device names so I don t have to care about the kernel detecting the disks and disk controllers in a different order on each reboot also makes it easier to identify which disk is having a problem as I can squint at the front of the drives in my Lian Li 4-in-3 hotswap bays and read the serial number sticker) OK, yeah, sure it s not that much different from replacing a dying drive in an mdadm or hardware raid array but one nice advantage of zfs over raid is that it only resyncs the data in use, not the empty or unused blocks. given that these are 1TB drives in a raidz vdev, and the pool is 63% used that means syncing only about 630GB rather than 1TB. ps: in the time it s taken to write this, it s up to 10.11% done. 88MB/s reading data from the existing raidz drives and writing to a single drive isn t too bad at all. one of the reasons i like zfs is a post from: Errata

The Comprehensive R Archive Network, or CRAN for short, has been a major driver in the success and rapid proliferation of the R statistical language and environment. CRAN currently hosts around 3400 packages, and is growing at a rapid rate. Not too long ago, John Fox gave a keynote lecture at the annual R conference and provided a lot of quantitative insight into R and CRAN---including an estimate of an incredible growth rate of 40% as a near-perfect straight line on a log-log chart! So CRAN does in fact grow exponentially. (His talk morphed into this paper in the R Journal, see figure 3 for this chart.) The success of CRAN is due to a lot of hard work by the CRAN maintainers, lead for many years and still today by Kurt Hornik whose dedication is unparalleled. Even at the current growth rate of several packages a day, all submissions are still rigorously quality-controlled using strong testing features available in the R system. And for all its successes, and without trying to sound ungrateful, there have always been some things missing at CRAN. It has always been difficult to keep a handle on the rapidly growing archive. Task Views for particular fields, edited by volunteers with specific domain knowledge (including yours truly) help somewhat, but still cannot keep up with the flow. What is missing are regular updates on packages. What is also missing is a better review and voting system (and while Hadley Wickham mentored a Google Summer of Code student to write CRANtastic, it seems fair to say that this subproject didn't exactly take off either). Following useR! 2007 in Ames, I decided to do something and noodled over a first design on the drive back to Chicago. A weekend of hacking lead to CRANberries. CRANberries uses existing R functions to learn which packages are available right now, and compares that to data stored in a local SQLite database. This is enough to learn two things: First, which new packages were added since the last run. That is very useful information, and it feeds a website with blog subscriptions (for the technically minded: an RSS feed, at this URL). Second, it can also compare current versions numbers with the most recent stored version number, and thereby learns about updated packages. This too is useful, and also feeds a website and RSS stream (at this URL; there is also a combined one for new and updated packages.) CRANberries writes out little summaries for both new packages (essentially copying what the DESCRIPTION file contains), and a quick diffstat summary for updated packages. A static blog compiler munges this into static html pages which I serve from here, and creates the RSS feed data at the same time. All this has been operating since 2007. Google Reader tells me the the RSS feed averages around 137 posts per week, and has about 160 subscribers. It does feed to Planet R which itself redistributes so it is hard to estimate the absolute number of readers. My weblogs also indicate a steady number of visits to the html versions. The most recent innovation was to add tweeting earlier in 2011 under the @CRANberriesFeed Twitter handle. After all, the best way to address information overload and too many posts in our RSS readers surely is to ... just generate more information and add some Twitter noise. So CRANberries now tweets a message for each new package, and a summary message for each set of new packages (or several if the total length exceeds the 140 character limit). As of today, we have sent 1723 tweets to what are currently 171 subscribers. Tweets for updated packages were added a few months later. Which leads us to today's innovation. One feature which has truly been missing from CRAN was updates about withdrawn packages. Packages can be withdrawn for a number of reasons. Back in the day, CRAN carried so-called bundles carrying packages inside. Examples were VR and gregmisc. Both had long been split into their component packages, making VR and gregmisc part of the set of packages no longer on the top page of CRAN, but only its archive section. Other examples are packages such as Design, which its author Frank Harrell renamed to rms to match to title of the book covering its methodology. And then there are of course package for which the maintainer disappeared, or lost interest, or was unable to keep up with quality requirements imposed by CRAN. All these packages are of course still in the Archive section of CRAN. But how many packages did disappear? Well, compared to the information accumulated by CRANberries over the years, as of today a staggering 282 packages have been withdrawn for various reasons. And at least I would like to know more regularly when this happens, if only so I have a chance to see if the retired package is one the 120+ packages I still look after for Debian (as happened recently with two Rmetrics packages). So starting with the next scheduled run, CRANberries will also report removed packages, in its own subtree of the website and its own RSS feed (which should appear at this URL). I made the required code changes (all of about two dozen lines), and did some light testing. To not overwhelm us all with line noise while we catch up to the current steady state of packages, I have (temporarily) lowered the frequency with which CRANberries is called by cron. I also put a cap on the number of removed packages that are reported in each run. As always with new code, there may be a bug or two but I will try to catch up in due course. I hope this is of interest and use to others. If so, please use the RSS feeds in your RSS readers, and subscribe to the @CRANberriesFeed, And keep using CRAN, and let's all say thanks to Kurt, Stefan, Uwe, and everybody who is working on CRAN (or has been in the past).

You make backups? That s great! But are they usable? The very day you will need your backup to restore your infrastructure, are you sure this backup you make three months ago contains the only file you need to restart your production environment? Are you sure this backup is not corrupted? Are you sure you do not store irrelevant or empty files instead of the ones you will need one day? Brebis is a fully automated backup checker. Brebis is written in Python 3 (>=3.2) and comes under the GPLv3 license. The current version is 0.4 (direct download). Some features (extensive list of features available here):

• Support of tar files, compressed with gzip or bzip2 or not, zip files, gzip or bzip2 files and uncompressed trees of files.
• Identify corrupted archives, unexpected size or type for an archive, associated wrong hash sums, Unix rights and owner users/groups of the archive thanks to a list you provide.
• Inside the archive, identify missing files, unexpected ones, unexpected size of a file, wrong associated hash sums, unexpected mode, type or owner users/groups for a file thanks to a list you provide or generate from a given archive.

1. Non-resizable configuration windows. I have a 1920 1200 screen but the window manager provides no way to resize windows like the System Settings window. Result is that the window is quite small and, worse, has a scroll bar for no good reason when another hundred or so vertical pixels would easily display everything. Even another 30 or so horizontal pixels would allow more icons per line under Hardware, reducing the number of lines, and again allowing the entire list of available settings to be displayed without a scroll bar. Instead, to see all of the options I have to scroll down. And these people call themselves user-interface and usability experts. It's not up to the gnome developers to decide that I never need to resize certain windows or certain kinds of windows. It's up to me to decide that. They're not at my desktop, using my screen. I am.
2. No way to disable a shell extenstion from the command line. I installed the gnome-shell-extensions package and was trying out various extensions to see if they made gnome shell tolerable. Enabling one of them (i forget exactly which one), immediately displayed some "Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again." leaving me no option but to log out. An absolutely fucking useless error message. "Something" has gone wrong. A little fucking detail might help me to diagnose the problem and fix it. Like a trace of whatever the fuck it was doing when "Something went wrong". When i logged back in, it crashed again, with the same useless error screen. So, now I can't even log in to Gnome Shell. I've tried logging in to Fallback mode, but the Extensions tab is empty in gnome-tweak-tool (because, of course, nobody would want to configure Shell Extensions from fallback mode, would they?). I can't even find any way of listing which shell extensions are enabled, let alone disable one of them. Hell, I'd settle for disabling all of them, and then carefully re-enabling them one-by-one until I rediscovered the culprit.
3. Oh, wait. I finally found /org/gnome/shell/enabled-extensions in dconf-editor. it's a text field with an array of items. so far, so good. The "editor" (and i use that term very loosely) for text fields is garbage. It can't even wrap lines so that it displays the whole field without a horizontal scroll bar probably my all-time least favourite user-interface element. Have gnome devs never heard of multi-line text-edit fields? Rather than fuck around with a crappy GUI editor, it's far easier to:

   $ dconf read /org/gnome/shell/enabled-extensions > /tmp/extensions
   $ vi /tmp/extensions
   $ dconf write /org/gnome/shell/enabled-extensions "$(cat /tmp/extensions)"
   

   I guess now it's time to log out from fallback mode to find out if I can log back in to Gnome Shell again. [ nope. didn't work ]
4. Add non-resizable user-interface elements to item 1. above. So far, Gnome devs are doing a great job of regressing to the crap usability of the Windows GUI here s a useful rule of thumb for things like that: Every single window, every single user-interface element should be resizable and tweakable by the user. And the system should remember all user changes so that they don t have to waste a few minutes every time they run an app resizing things to suit their requirements. Gnome 2 mostly had that. Gnome 3 seems to have lost a large part of it along the way Second rule of thumb: If the user happens to replace their monitor or run it in a mode too small for the current settings, then they should revert to some sane default. Even better, it should remember the settings for each resolution choosing either sane defaults or the user s settings for the nearest similar resolution if the user hasn t created custom settings for that resolution yet.
5. Lack of documentation. here's a good example:

   $ gnome-shell-extension-tool help
   Usage: gnome-shell-extension-tool [options]
   $ man gnome-shell-extension-tool
   No manual entry for gnome-shell-extension-tool
   See 'man 7 undocumented' for help when manual pages are not available.

   What more needs to be said? At least /usr/bin/dconf has built-in help. Which is great, since it doesn't have a man page either.

Update: About three hours of stuffing around later, and I ve finally got Gnome Shell running again. I have NFI what actually fixed it, it could have any one of the dozens of settings I fucked around with. Nor do i have any idea what the actual problem was. And after all that, the extensions I tried still don t make Gnome Shell tolerable. They make it less *intolerable* (bottom-panel extension in particular), but that s still a long way from being tolerable i m really trying hard to find some way to come to terms with Gnome 3. I ve been trying for months now. But every time I give it another trial, I just end up hating it even more I m glad I have more than one desktop machine to use, so i can experiment with odious shit like Gnome Shell without fucking up my main working environment. So it s back to my main desktop machine and gnome2. Eventually I ll have to upgrade that, but xfce4 is looking to be my best option. I already switched to xfce4 on my desktop machine at work last week, and it s pretty good certainly far better than the Gnome 3 fallback mode i ve been using there for the last 5 or 6 months. Thanks, Gnome devs you re making a fantastic advertisement for XFCE. I wouldn t have bothered trying it again if I hadn t been forced to. ps: before anyone says wait for Gnome 3.2, it s much better . Todays waste of time *was* using Gnome 3.2 some more reasons to hate gnome shell is a post from: Errata

I have just released version 0.22 of Obnam, my backup application. Snippet from the NEWS file below. This version fixes a couple of bugs that could be said to be of the brown paper bag variety. USER VISIBLE CHANGES:

• Obnam now reports its current configuration in the log file at startup. This will hopefully remove one round of "did you use the --foo option?" questions between developers and bug reporters.

BUG FIXES:

• The repository is now unlocked on exit only if it is still locked.
• A wrongly caught GeneratorExit is now dealt with properly.
• Keyboard interrupts are logged, so they don't show up as anonymous errors.

CHANGES RELEVANT TO DEVELOPERS ONLY:

• setup.py has been enhanced to work more like the old Makefile did: clean removes more artifacts. Instructions in README have been updated to point at setup.py.
• Compiler warning about _XOPEN_SOURCE re-definition fixed.
• Tests are now again run during a Debian package build.

Happy. This is how I feel after I ran the "Le Puy-Firminy" night race last Sunday. 70 kilometers (mixed roads and trails), 1500 meters positive slope, close to my birth town, St-Etienne (the track on Garmin Connect unfortunately has bugs for the profile, sorry for this....this is apparently a bug in Garmin Connect as pyTrainer shows the track very well. And running this by night, starting at midnight and arriving at....09:16 the next day. A full night running. Such "ultra" experience is completely different from marathon running. In marathons, you mostly try keeping a constant pace all along the race, running very close to your limits all along the race. Very long distances involve managing much more than keeping a constant pace. Being able to run (and walk) for many hours requires being very careful at the start of the race, controlling the pace and save energy for the last part of the race. Climbing is most of the time done by walking (except for the very first runners) and going down for kilometers is very hard for legs, even at slow paces. Night running is also making things a lot different. Particularly in a quite small race like this one, it means running alone most of the time. And, by alone, I really mean alone. You and your head lamp, that's all. I am very happy about the way I managed this race. I reached the 32km mark, where an important food/drink point was organised, in a little bit more than 3 hours 15 minutes, where I stopped about 7-8 minutes. That was followed by about 5 kilometers downhill, at 6%, on a paved road, which is really killing legs. The marathon distance was reached in about 5h05, more or less what I planned, but that race is known to be harder in its second half. And completing a marathon, *then* knowing that you still have 2/3 of a marathon to run is kinda challenging..:-) Another important moment of the race was the 55 kilometer mark. This, because this was the longest distance I ever ran in a single race (in March, for the Paris Ecotrail race). Of course, the longer you run, the harder are legs and what was expected happened to me: I had cramps in both legs, at the worst moment, around km 64, when the track brutally goes down for 150 meters in a small canyon, then goes up for about 200 meters. Indeed, I completed kilometer 66 in....22 minutes (I see my marathon runners friends laughing here). This is indeed where you know if you're strong and motivated enough : not abandoning, continue despite cramps, waiting for them to disappear...and finally complete the race. It was really worth it anyway : running by night is really magic. I still remember the though moments at 5am, in the moonlight, alone on a road...and so happy to be there..:-) That race was the last one for me this year. I followed my plans (the only regret being not beating my record at Berlin marathon). Next year plans include two marathons: probably Caen ("Les Routes de la Libert " along the D-Day beaches in Normandy) in June and another one during Fall. I'll also push my limits a bit further with the 80km race of Ecotrail, arriving at Eiffel Tower first floor after running through forests in the SW area of Paris....and probably again that 70km race in November. Once you've tried ultra races, you don't want to stop..:-) Until the end of the year....recovery...and training. After all, Ecotrail is only in 4 months..:-)

It s general election time again in New Zealand this year, with the added twist of an additional referendum on whether to keep MMP as our electoral system. If you re not interested in New Zealand politics, then you should definitely skip the rest of this post. I ve never understood why some people consider their voting choices a matter of national security, so when via Andrew McMillan, I saw a good rationale for why you should share your opinion I found my excuse to write this post. Party Vote
I ll be voting for National. I m philosophically much closer to National than Labour, particularly on economic and personal responsibility issues, but even if I wasn t the thought of having Phil Goff as Prime Minister would be enough to put me off voting Labour. His early career seems strong, but lately it s been one misstep and half-truth after another, the remainder of the Labour caucus and their likely support partners don t offer much reassurance either. If I was left-leaning and the mess that Labour is in wasn t enough to push me over to National this year then I d vote Greens and hope they saw the light and decided to partner with National. Electorate Vote
I live in Dublin, but you stay registered in the last electorate where you resided, which for me is Tamaki. I have no idea who the candidates there are, so I ll just be voting for the National candidate for the reasons above. MMP Referendum
I have no real objections to MMP and I think it s done a good job of increasing representation in our parliament. I like that parties can bring in some star players without them having to spend time in an electorate. I don t like the tendency towards unstable coalitions that our past MMP results have sometimes provided. Of the alternatives, STV is the only one that I think should be seriously considered, FPP and it s close cousin SM don t give the proportionality of MMP and PV just seems like a simplified version of STV with limited other benefit. If you re going to do preferential voting, you might as well do it properly and use STV. So, I ll vote for a change to STV, not because I m convinced that MMP is wrong, but because I think it doesn t hurt for the country to spend a bit more time and energy confirming that we have the right electoral system. If the referendum succeeds and we get another referendum between MMP and something other than STV in 2014, I ll vote to keep MMP. If we have a vote between MMP and STV in 2014 I m not yet sure how I d vote. STV is arguably an excellent system, but I worry that it s too complex for most voters to understand. PS. Just found this handy list of 10 positive reasons to vote for National, if you re still undecided and need a further nudge. Kiwiblog: 10 positive reasons to vote National

Could you not trust this man?Max and Fraser are very interested in this year's election. I guess political awareness starts at the first election after you turn 10, or so. They're both very curious about how mum and dad are voting, and while their mother will not tell (though we all have our suspicions :-) I don't see any reason not to discuss my political leanings with them.I've been what is commonly termed a 'floating' voter for most of my voting life. I imagine the politicians themselves might term people like me 'floaters', with an eye to the scatalogical implications. After all, their livelihoods are on the line!So, after reading this blog post I thought I might as well also share my personal voting plans with the world.

Andrew Cowie blogs about 'A good GNOME 3 Experience'. He writes

I think it s a bit odd not to expect that something that was widely advertised as being such a different user experience is different.

and

if they had gone and bought an Apple laptop with Mac OS X on it they would be perfectly reasonably working through learning how to use a new Desktop and not complaining about it at all. But here we are admonishing the GNOME hackers had the temerity to do something new and different.

I think Andrew's phrasing here is a bit disingeneous. Or perhaps he genuinely mistakes the frustration that has been felt by GNOME 3. I don't want to whine on too much, so I'll try to get this out of the way in one paragraph. F/OSS users are members of a community. There is inevitably a wall between the majority of community members and the blessed: the decision makers, the developers. The art of maintaining a good community is partly to do with making this wall as invisible as possible: encouraging participation, lowering the barrier for contributions; welcoming feedback; etc.1. The GNOME community have invested a lot into the GNOME 2 way of doing things, and GNOME 3, by breaking away from that so fundamentally, has devalued the community's investment. It screams: we don't want your panel widgets! We don't want your themes! Your working practices are wrong: this is the right way! GNOME 3 is opinionated software, and it's opinion differs from a large body of the GNOME community. The result? resentment. Remember: GNOME 3 is not just something new: it's the abrupt termination of something old, tried and tested. and hopefully that's the last time I need to vent about my GNOME 3 frustration. It's hear to stay, the question for the frustrated is: are you? Moving on Andrew goes on to recommend:

One thing I do recommend is mapping (say) CapsLock as an additional Hyper You do the mapping in: System Settings Keyboard Layout Layout tab Options..

I used to do this with GNOME 2, but I couldn't find how to do it on GNOME 3. Andrew's post gave me the important hint that it was still possible, but the precise location doesn't match: On my Fedora 16 / GNOME 3.2 system, it's System Settings Region and Language Layouts Options ". This is especially useful on my beloved UltraNav keyboard which lacks the Windows 95 keys. Sadly it does not work very well through various remote desktop tools: I get an inconsistent capslock state within VMs connected to via VNC. rdesktop seems ok.

While working on SAT-Britney, I made heavy use of the IntSet data type provided by the basic Haskell library containers . Since memory consumption was a problem, I looked at its implementation, which is a binary tree, and wondered whether this could be improved for dense sets by using a machine sized word as a bit map to represent a continuous part of the integers, so I started to implement it. The effect on my program was not as strong as I had hoped for, but nevertheless, the code made its way back into containers after a thorough review and a considerable amount of further improvements by Milan Straka. I m getting sucked deeper and deeper into the Haskell community... (which means that the Haskell community does not suck, of course.)
Flattr this post

Yesterday evening I updated my server to remove MySQL:

steve:~# dpkg --purge mysql-client-5.1 \
                      mysql-common     \
                      mysql-server-5.1 \
                      mysql-server-core-5.1 \
                      python-mysqldb        \
                      libdbd-mysql-perl     \
                      libdatetime-format-mysql-perl

Until last month I had two database in use, one each for a pair of web-applications. As of now one is using redis - which I'm already using for my image hosting - and the other application is using SQLite. Until recently I had a high opinion of SQLite, although that has now been downgraded a little, it is still a thoroughly excellent piece of software. I was just surprised at little things it was missing, to the extent I had to rewrite my applications SQL. Still one less service is a good thing, and the migration wasn't so painful.. In more productive news I recently acquired a nice external flash - the Yongnuo YN-460 II is (very) cheap and cheerful, it can be fired remotely with my triggers so I've had a lot of fun with opportunistically taking pictures and experimenting with lighting. Most of the results are NSFW, but there are some other examples lurking around including the first time I managed to successfully capture a falling water-drop. (Not the best picture, not the most explicit effect, but fun regardless. I both can and will do better next time!)

Somebody recently asked me to write about "camera stuff under linux" and happily I declined. Why decline? Because there are so many good tools, applications, and utilities. (I use local tools for organisation and duplicate detection, rawtherapee for RAW conversion and GIMP for touchups). Having many available options is fantastic though, and something hard to appreciate for "newcomers" to Linux. (Yeah I waited 90 seconds - if I remembered to add -nojava - for Netscape Navigator to start, under X10, with 8Mb of RAM. Happier days are here. Sure DRM is bad, secure boot .. an open question, but damn we have it good compared to almost any previous point in time!)

ObQuote: "Yeah, obviously it is only a tactical party. I'm only having a party to eventually get sex." - Peep Show

This is both a release announcement for the next installment of The MirBSD Korn Shell, mksh R40b, and a follow-up to Sune s article about small tools of various degrees of usefulness. I hope I don t need to say too much about the first part; mksh(1) is packaged in a gazillion of operating environments (dear Planet readers, that of course includes Debian, which occasionally gets a development snapshot; I ll wait uploading R40c until that two month fixed gcc bug will finally find its way into the packages for armel and armhf. Ah, we re getting Arch Linux (after years) to include mksh now. (Probably because they couldn t stand the teasing that Arch Hurd included it one day after having been told about its existence, wondering why it built without needing patches on Hurd ) MSYS is a supposedly supported target now, people are working on WinAPI and DJGPP in their spare time, and Cygwin and Debian packagers have deprecated pdksh in favour of mksh (thanks!). So, everything looking well on that front. I ve started a collection of shell snippets some time ago, where most of those small things of mine ends up. Even stuff I write at work we re an Open Source company and can generally publish under (currently) AGPLv3 or (if extending existing code) that code s licence. I chose git as SCM in that FusionForge instance so that people would hopefully use it and contribute to it without fear, as it s hosted on my current money source s servers. (Can just clone it.) Feel free to register and ask for membership, to extend it (only if your shell-fu is up to the task, KNOPPIX-style scripts would be a bad style(9) example as the primary goal of the project is to give good examples to people who learn shell coding by looking at other peoples code). Maybe you like my editor, too? At OpenRheinRuhr, the Atari people sure liked it as it uses WordStar like key combinations, standardised across a lot of platforms and vendors (DR DOS Editor, Turbo Pascal, Borland C++ for Windows, ) ObPromise: a posting to raise the level of ferrophility on the Planet aggregators this wlog reaches (got pix)