New Debian-based security distribution. The company behind BackTrack (Offensive Security) have just launched Kali Linux which will be tightly coupled to Debian and use Debian security updates, for example.

See also: http://www.kali.org/ and Raphael Hertzog's more informative post on Planet Debian.

I've just pushed out the release files for Obnam version 1.4, my backup application, and Larch, my B-tree library, which Obnam uses. They are available via my home page (http://liw.fi/). Since Debian is frozen, I am not uploading packages to Debian, but .deb files are available from my personal apt repository for intrepid explorers. (I will be uploading to Debian again after the freeze. I am afraid I'm too lazy to upload to experimental, or do backports. Help is welcome!) From the Obnam NEWS file:

• The ls command now takes filenames as (optional) arguments, instead of a list of generations. Based on patch by Damien Courouss .
• Even more detailed progress reporting during a backup.
• Add --fsck-skip-generations option to tell fsck to not check any generation metadata.
• The default log level is now INFO, instead of DEBUG. This is to be considered a quantum leap in the continuing rise of the maturity level of the software. (Actually, the change is there just to save some disk space and I/O for people who don't want to be involved in Obnam development and don't want to have massive log files.)
• The default sizes for the lru-size and upload-queue-size settings have been reduced, to reduce the memory impact of Obnam.
• obnam restore now reports transfer statistics at the end, similarly to what obnam backup does. Suggested by "S. B.".

Bug fixes:

• If listing extended attributes for a filesystem that does not support them, Obnam no longer crashes, just silently does not backup extended attributes. Which aren't there anyway.
• A bug in handling stat lookup errors was fixed. Reported by Peter Palfrader. Symptom: AttributeError: 'exceptions.OSError' object has no attribute 'st_ino' in an error message or log file.
• A bug in a restore crashing when failing to set extended attributes on the restored file was fixed. Reported by "S. B.".
• Made it clearer what is happening when unlocking the repository due to errors, and fixed it so that a failure to unlock is also an error. Reported by andrewsh.
• The dependency on Larch is now for 1.20121216 or newer, since that is needed for fsck to work.
• The manual page did not document the client name arguments to the add-key and remove-key subcommands. Reported by Lars Kruse.
• Restoring symlinks as root would fail. Reported and fixed by David Fries.
• Only set ssh user/port if explicitily requested, otherwise let ssh select them. Reported by Michael Goetze, fixed by David Fries.
• Fix problem with old version of paramiko and chdir. Fixed by Nick Altmann.
• Fix problems with signed vs unsigned values for struct stat fields. Reported by Henning Verbeek.

Dear project members, here's another report of DPL activities, this time for a period longer than usual (February + 1st week of March), so that the next one will be at the very end of the current DPL term. Highlights

• As you know, we are now well within the DPL election process. And we have 3 valuable candidates running. I encourage all of you to participate in the discussions on -vote, and ask questions about project vision, goals, and improvements. It's something that is rarely as intense as during campaigning, so don't miss the chance!
• You might have noticed a sharp decrease in the count of RC bugs affecting Wheezy; that is largely due to the Release Team, who started the usual final sweep of RC triaging before release. Please thank them for their work, ... but don't give up on our collective work yet! You can still help up in the usual ways (NMUs, severity adjustments, unblock reviews, etc).
• The technical committee had to deal with a rather urgent issue during last month (#699808). I mention it here only to applaud their efficiency in doing so: 4 days to reach a decision. Resorting to tech-ctte shall always remain a last resort in Debian, but when it comes to that it's useful to know that we can count on a wise and speedy answer.

Appointments

• As the previous term was about to end, I've agreed with the Kurt Roeckx to re-appoint him as Project Secretary for another year.
• Following up to last month news, we've now assembled a team of admins for Debian participation into Google Summer of Code 2013 and delegated them for the task. Many thanks to David, Nicolas, Paul, and Sukhbir for volunteering, as well as to last year admins for their help in reaching out to interested volunteers. On a related note, we've until March 28th to propose projects and/or volunteer as (co-)mentor for GSoC 2013.

DPL helpers Two more DPL helpers IRC meetings have happened, minutes and logs of both are available. Assets

• I've worked with the press and publicity teams to announce the new trademark policy more widely and call for producing Wheezy merchandise. Apparently, we are now also being cited as a reference on how to strike a balance between free software and trademark (unfortunately the article is behind a paywall now).
• In related news, Brian Gupta has volunteered to help with answering trademark@d.o inquiries and has already helped a lot in streamlining the process and keeping track of past requests (thanks!)
• Following a -project inquiry by Thomas Koch, I've investigated with SPI the possibility of assigning to them the copyright for (code) contributions to Debian. The bottom line is that at present there is no safe way to do that with SPI; that might change in the future.
• As agreed at a DPL helpers meeting, we are trying to federate interests in Debian sponsoring and fund-raising. Part of the goal is avoid duplication of efforts DebConf- and sponsoring for other Debian activities; and part is establishing a more stable income flow for Debian (to ease long-term budget decisions). If you have experience and interest in this area, please join the debian-sponsors-discuss list on Alioth.
• Together with auditors, we have updated reimbursement procedures to better keep track of both outstanding and past requests. Main difference is that you'll now have to mail a RT queue instead of leader@d.o directly. Check the wiki page for details.

Events Past At the beginning of February, I've attended FOSDEM 2013, together with many other Debian people. I didn't have any specific talk this year, but it's been a chance to talk F2F about several ongoing issues (see logs), and help mediating in some conflicts. I've also accepted the invitation to participate in the GNOME Advisory Board meeting, together with Laurent Bigonville of our GNOME team. No report of that has been prepared as of yet (sorry about that), but we have both reported "live" to the rest of the team on IRC. Future

• It looks like my last month as DPL will be quite busy. Next week I'll be first in New York City, delivering an invited Debian talk at NYLUG (thanks a lot to Brian Gupta and Tom Limoncelli for the invitation). Then I'll head to LibrePlanet 2013 to talk about the relationship between Debian and GNU (thanks to John Sullivan for the invitation). Finally, at the beginning of April, I'll be in Amsterdam to deliver a talk about Debian experience with various legal issues across the years, at the yearly FSFE Legal and Licensing Workshop (thanks to Karsten Gerloff for the invitation). Both trips (LibrePlanet and FSFE) will be on Debian budget. While I usually insist on having travel sponsorship from inviting entities, in this cases I've accepted to do otherwise given they are free software non profits like Debian.
• I've been invited to represent Debian at Distro Recipes. Due to a conflict with FSFE workshop I couldn't make, so I've looked for substitutes. Lucas Nussbaum and Jonas Smedegaard have kindly accepted to go in my stead and deliver two talks, one about QA and the other about Pure Blends; thanks folks!

Miscellaneous A couple of months ago I've mentioned that I had filed an application, as Debian representative, to participate in a working table to define software procurement rules for the Italian public administration. Good news: my application has been accepted, together with those of other well-known FOSS communities and organizations (e.g. KDE, FSFE). I'll keep you posted of how it goes. Let's go back to elect a new DPL and release Wheezy now,
Cheers.

---

PS the day-to-day activity logs for February and March 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 2,3

I've a collection of about 500 bookmarks which I've barely touched for a few years. I started organizing them late the other night, because I'd been off work sick for two days and that was about the most I felt up for doing with a computer. The intention was to "tidy" them, and then setup some way of syncing them across browsers/computers. In the end I didn't like any of the syncing plugins I could find - xmarks, etc - so I decided to take a step backwards. I'd exported my bookmarks to HTML page, via firefox, before I started, and then later in a fit of pique I deleted the whole damn lot of them. So now a few years worth of bookmarks are stored in a single HTML file. But wait, we can use revision control can't we? We can host that file on github/similar. We can rely upon merges to deal with conflicts - simple if we just add lines to the end, or delete lines. Maybe that's the best way to store bookmarks? I updated the bookmark file to read:

<ul>
<li tags="debian, personal"><a href="http://www.debian-administration.org/">Debian Admin</a></li>
..
</ul>

Adding "tags" to the LI-container and then some simple jQuery code gave me the ability to search/filter the bookmarks and auto-populate tags. A small example placed online here:

• http://www.steve.org.uk/Software/bookmarks/

The obvious comment is that this makes adding new bookmarks a bit harder, but we'll see.. The javascript works in the browsers I tested, and for those that have none the bookmarks will just be a simple unordered list which should be universal. I expect the javascript could be improved by a real developer.

A boy died. He knew he was dying. He tried to get help. We don't know if it occurred to him to switch off the modem and make a phone call, or if he was too weak to get up and do it. We know he sent an email. He didn't type perfect English at the best of times, and as his life slipped away from him, he misspelled many things. He misspelled ambulance . He may have misspelled diabetes . That was all fine the meaning was clear enough but the bit where it gets tragic is that he misspelled .net in the To: line. So instead of arriving at its destination, the NOC of his employer, where it would have opened up a ticket and been seen by a human at some point, the email bounced. We will never know whether they could have or would have done anything in time. We will never know if, had whoever been on postmaster duty at his ISP at the time been paying attention, he could have been saved. These things were debated angrily, by people struggling to make sense of something, but it changes nothing. The email bounced, and he died.

Captain Awkward, which is still the best advice column on the Internet, just posted an entry about someone being pestered to drink after saying that they don't drink. As another one of those people who just don't drink, but not for any specific reason that people seem to accept, I felt like blathering a bit more about that. This is mostly about me rather than about the thread over there, so I figured I'd do it on my own journal. First, I completely agree with the response that it's no one else's business why you do or don't drink, and people who persist in trying to get you to drink (or do anything else, no matter how innocuous) after you have clearly told them no are being rude and have forfeited the right to further conversation. But it also really frustrates me to see that people have to cope with that situation, particularly since I suspect it's gendered. My personal experience (as a man, and one who has a fairly firm way of expressing myself naturally) is that I say I don't drink and that's the end of it. Occasionally someone will ask me why. I've never had anyone pester me beyond that. I think the age of the letter writer (22) has something to do with this, but I suspect gender sadly also has something to do with this. People seem to be much more willing to tell women what to do and not take no for an answer. It's unbelievably rude when people do that. Don't do that. If you decide you can pester someone about their personal choices because of their gender (and, for that matter, their age, or any other reason), you deserve to get your head handed to you on a plate. Second, I wonder if some of the reason why I don't run into problems with this is that I work on a college campus. The latter means that there's a lot of surrounding culture around drinking and dealing with drinking, such as the university policy that any party have EANABs (Equally Attractive Non-Alcoholic Beverages) available as well. There's a bit of a cultural understanding that pushing people into drinking isn't okay. Third, since people do occasionally ask why I don't drink, or assume that anyone who doesn't drink is doing so for religious reasons or because they're an alcoholic, or might object to them drinking, here are a few reasons why I don't drink. It may be useful information in case you run into more people in the world like me.

• Due mostly to accident, and certainly not due to any specific effort on my part, I made it to late teenage years without ever having any significant amount of alcohol. That means I never developed a taste for it. (I didn't develop an aversion to it either; I just have no opinion on it. I've had just enough of it to know how it tastes, such as the occasional socially-indicated glass of wine, but not enough to form any opinions.) After that point, I figured since I'd not had it yet, there was no reason to start. Now, some years later, I already have more hobbies and things I enjoy than I have time and attention for, and I'm no longer at the point of my life where I'm actively seeking out new ones just because lots of other people enjoy them.
• If alcohol isn't going to be a hobby, and is just something else to drink, well, alcohol is expensive and generally fairly high-calorie. In general, I only drink things that have no calories because I like to drink a lot and I prefer to save my available calories for food (which I generally enjoy more). Why not save my money and spend the calories on something I know I enjoy?
• I really hate all of the physical symptoms (headache, nausea, unsteadiness, lack of emotional control, dizziness) one gets from overdrinking when I've gotten them via other means. I know that one doesn't necessarily get drunk when one drinks, and one can avoid getting that drunk even if one gets drunk, but given that I've never developed any taste for alcohol, why bother to start on something that I've seen lead to really nasty physical symptoms in lots and lots of my friends?
• I'm remarkably stubborn about things that I do that other people don't do. Show me cultural pressure contrary to something I'm currently doing, even if I'm only doing that thing by accident, and I tend to make it a point of pride for no other reason than I dislike pressure. (I probably subconsciously exude this, which is probably part of the reason why people don't argue with me.)

So, that's me. It makes no difference at all to me if other people drink. Enjoy! You won't offend me, there isn't any overtone to it, I'm not being judgemental when I say I don't drink, and it's not a dangerous topic or anything. There are probably others like me. If you run into us, all you have to say after "no thanks, I don't drink" is "oh, okay."

This package is my pure C test harness that understands the TAP protocol. It's akin to prove, except written in C. It also provides a TAP library for C and shell scripts, which is useful even if you don't want to use the harness. I was going to just do a small release with no major changes, just some cleanup and merging of changes from elsewhere, but I do hate making tiny releases and I'd been meaning to get back to doing some larger development for a while. So this release has several major changes, including one backward-incompatible one. The backward-incompatible change is that, to specify a list of tests to run, one now needs to use the -l option to runtests. That's because the default interpretation of the command line is now that it is a list of tests to run and summarize. This is more consistent with other test harnesses, such as prove. Also in this release, runtests will look for the test name as given if it can't find it by appending -t or .t, which allows one to pass the actual name of the test executable on the command line (with or without the -o option). This makes command-line completion less annoying. There are a few other minor fixes to display: output is flushed after each test executable completes even if the output isn't a terminal, which produces better display when teeing to a log file, and partial status of tests that use lazy plans now show the total test count as "?" to match the behavior of prove. I also fixed a few errors when displaying a test abort to a terminal. You can get the latest version from the C TAP Harness distribution page.

A bug I've recently seen in production code gave me the idea for this blog post. Probably smarter people already wrote better things on this topic, so this is mostly for myself, to better summarise my own thoughts. Corrections are welcome, please leave a comment! Let's say we have a somewhat standard API in Python or C++:

• a function (init_t) to create/initialise our data type, which returns an object of type t
• the object then has some properties or methods that we can call

Signalling failures to initialise the object can be done in two ways: either by raising an exception, or by returning a null/None result. There are advantages and disadvantages to both:

• if using exceptions, then you must be sure to catch and handle all possible exceptions that the initialisation function can raise (otherwise more of your code can be aborted than you want)
• if using None as return value, then you must check that the value is correct before using it, otherwise you get an exception or null pointer dereference

The None model can create latent bugs, for example in the following code:

ok = True
for arg in input_list:
  t = init_t(arg)
  if t is None:
    ok = False
    continue
  t.process()
return ok

The presence of the continue statement there is critical. Removing it, or moving it after some other statements which work with t will result in a bug. So using value-based returns forces us to introduce (manually) control points, without having the possibility to validate the model by the compiler (e.g. in C++). So it would seem that this kind of latent bugs pushes us to use the exception model, with its drawbacks. Let's look at how this interface would be implemented in (IMHO) idiomatic Haskell (where the a and b types represent the input and output types):

initT :: a -> Maybe T
processT :: T -> b
my_fn =
  
 case initT arg of
   Nothing -> -- handle failure
   Just v -> processT v

Yes, this can be written better, but it's beside the main point. The main point is that by introducing a wrapper type around our main type (T), we are forced via the type system to handle the failure case. We can't simply pass the result of initT to a function which accepts T, because it won't type check. And, no matter what we do with the result value, there are no exceptions involved here, so we only have to think about types/values, and not control flow changes. In effect, types become automatically-validated control-flow instructions. Or so it looks to me . So using types properly, we can avoid the exception-vs-return-value debate, and have all advantages without the disadvantages of either. If that is the case, why isn't this technique used more in other languages? At least in statically typed languages, it would be possible to implement it (I believe), via a C++ template, for example. In Python, you can't actually apply it, as there's no static way of enforcing the correct decapsulation. I was very saddened to see that Google's Go language, which is quite recent, has many examples where initialisation functions return a tuple err, value = , separating the actual value from the error, making it not safer than Python. It might be that polymorphic types are not as easy to work with, or it might be the lack of pattern matching. In any case, I don't think this was the last time I've seen a null pointer dereference (or the equivalent AttributeError: 'NoneType' object has no attribute ). Sadly You can even go further in Haskell and introduce more control flow structure via wrapper types. Please bear another contrived example: an HTML form that gets some input data from the user, validates it, saves it to the database, and echoes it back to the user. Without types, you would have to perform these steps manually, and ensure they are kept in the correct order when doing future modifications. With types, you only have to design the types correctly and export only smart contructors (but not the plain ones):

module Foo ( ValidatedValue
           , validateValue
           , RecordId
           , CommittedValue
           , commitValue
           , buildFeedbackForm
           ) where
data ValidatedValue a = ValidatedValue a
validateValue :: a -> Maybe (ValidatedValue a)
data RecordId =  
data CommittedValue a = CommittedValue a RecordId
commitValue :: ValidatedValue a -> ComittedValue a
buildFeedbackForm :: CommittedValue a -> HTMLDoc

From these types, it follows more or less that the only correct workflow is:

1. get a value from the user
2. validate it
3. commit it, getting a transaction/record ID
4. send the response to the user

In other words:

handleFeedbackForm = buildFeedbackForm . commitValue . validateValue

There are still issues here, e.g. the type a is completely hidden behind the wrapper types, and we can't recover some basic properties (even if we use newtype, unless we use GeneralizedNewtypeDeriving). But it does offer a way to improve control flow safety. And that is my 0.02 currency unit for today.

...we stopped the singing. This may be irony:

No More Google Reader
from Google Operating System by Alex Chitu
via What's Hot in Google Reader

but the topic at hand remains serious. This is a stark reminder of why it's important to be able to get your data out of cloud services at a moment's notice and why you should always keep local backups of important data. Thankfully, Google is quite fair about this, as opposed to a lot of other large players. (As a side note, export of full data should be doable, but come with another layer of security like a grace period, password confirmation, verification email, or other means. Imagine someone gains temporary access to your account and exports all your digital life at once. And yes, I know how that relates to IMAP.) Google Reader has felt like a second class citizen for quite some time now, the removal of features to push Google+ and the slow updates for Android were two signs that didn't forebode well (Vim's spelling correction does not know "forbode", how weird is that)(turns out I'm simply stupid, see comments; thanks Jim). I can see how this move may make sense from Google's POV even though I am sad to see an old companion go. Anyway, the stats page of two of my accounts show how sadly I will miss Google Reader in two simple lines:

Since January 24, 2010 you have read a total of 59,253 items.
Since February 20, 2011 you have read a total of 215,285 items.

Farewell, my friend. PS: Maybe those petitions will sway them, but I won't get my hopes up. PS: Speaking of Google, I found this gem today; TMI.

While working on fixing a few encoding problems that I managed to introduce to the BTS almost half a year ago, I took a side bit of coding, and introduced libravatar support to the BTS. Every e-mail now has an avatar to the right which should correspond to the sender. Libravatar is a federated service, which means that if you control your domain, you can serve your own icons. It also automatically falls back to gravatar, so if you're using that service, things should "just work". Hopefully this will be primarily amusing, and people won't abuse it. More importantly, but much less fun, the double encoding problems (where mails would get double-encoded if any of the headers contained non-us-ascii text), and mojibake wontfix icon ( ) should be fixed now. If you see any additional cases of this, please report them to owner@bugs.debian.org.

sage@guug This January, I held an updated version of my "Gitify your life" talk at sage@guug, which is the Munich chapter of the German Unix User Group. Once again, it was quite successful and turnout was about three times that of normal attendance. Afterwards, I was asked if I would be willing to hold the same talk at the German Unix User Group's Spring Meeting in 2014 as the programme for 2013 has been finalized for quite some time, already. Obviously, I said I would be willing to do that and will submit the talk once registration opens. Open Source Days By the way, I am writing this post from a hotel room in Copenhagen. Tomorrow, there will be a world first... "Gitify your life" will not only be held as a talk, it will be expanded into a full three hour workshop (with the option of extending it if there's interest as the room will be free after my workshop). Having never held a workshop of this scope, I am really looking forward to this experience. Besides enabling me to get people up and running with their personal data, this will allow me to see where new users are having issues with vcsh. I keep hearing of people not getting their heads around the concept easily, but no matter how many promises of updates to my docs I get while helping them, no one really follows through with that promise once they know how to use vcsh. Maybe I will find someone willing to follow through and/or simply gather enough material for docs 2.0. Your place? As an aside, and I will probably try to put a real announcement together as well, if you know of a conference, user group or other place where a lightning talk, a full talk, or a workshop about one or all of these topics would fit, please let me know. I will gladly submit proposals to or accept invitations from most places as long as I can spread this message. Especially if the venue happens to be reasonably close to Southern Germany, covers travel cost, or if they can guarantee video recording of the talk. Joey Hess has speculated if the talk isn't really called "git naked" as I seem to keep on giving that particular talk at venues which don't have video recordings. Please help me make Joey happy... ...with a video recording, I mean.

Hi everyone! Today I make an announcement I thought I would never ever make. But things changed. Discussion about this has a long history, starting as a non-serious suggestion at DesktopSummit 2011, continued with people on IRC, but it was decided back then that it wouldn t be worth the effort. This has changed too, and a small team has formed to work on it. We hereby announce Tanglu, a new Debian-based-Linux distribution. Why do we need another one? Let me explain the concepts of that distro: Tanglu will be based on Debian Testing and follow the Debian development closely. It will have a 6-months release-cycle and it s target audience are Linux desktop users. We will make installing and setting up the distro as easy as possible. Tanglu will be usable for both developers of upstream software and the average Linux user and Linux newbie. This is possible because in our opinion developers and users don t have different needs for a desktop system. Both kinds of users like a polished desktop which just works . We will, hwever, not apply any kind of fancy modification on upstream software, we will basically just distribute what upstream created, so users can get an almost pure GNOME and KDE experience. Tanglu is designed to be able to solve the issue that Debian is frozen for a long time and Debian Developers can t make new upstream versions available for testing easily. During a Debian freeze, DDs can upload their software to the current Tanglu development version and later start the new Debian cycle with already tested packages from Tanglu. The delta between Tanglu and Debian should be kept as minimal as possible. However, Tanglu is not meant as experimental distribution for Debian, so please upload experimental stuff to Experimental. Only packages good enough for a release should go into Tanglu. Ideally, Tanglu and Debian should be working well together in mixed environments, where you for example have Debian servers and multiple Tanglu desktops with the new software, targeted at desktop user. Since the differences between Tanglu and Debian should not be very high, administering both systems should be very easy (if you know Debian). Tanglu will be an open project, driven by community. At the beginning of each cycle, people can make suggestions for release goals they want to implement (similar to Fedora, but without FESCo). These proposals are discussed in public and are rejected if there are major technical concerns. If consensus about a certain proposal is lacking, a vote is done for it. The proposal can be accepted with absolute majority. If this does not happen, the proposal is postponed for the next release, where people can vote for it again. If nobody wants that function, it is rejected. In general, decisions made by Debian are superior and have to be followed. We don t think we know every package and every software better than the original upstream. That s why it makes much sense to rely on feedback from others and to have a community-based and peer-reviewed distribution, instead of secretly developing stuff and dumping it on the community. Tanglu will have a highly predictable set of features, defined at the beginning of a cycle, so you will know what you can expect from the next release as soon as possible and plan for it. Tanglu will make it easy to deploy applications for it. It will contain a software-center, similar to what Ubuntu has. We will also try to establish a solution for a Linux-AppCenter , a place for Linux applications, which will be open not only for Tanglu, but can be implemented in any other distribution too. Possible income will flow back into development of the platform. Now, let s answer the FQA (Future Questions Asked): Why don t you contribute to Debian directly and create yet another distribution? First of all, we contribute to Debian And for me, I can say that I will contribute to Debian even more. The point is that Debian can not cover all possible use-cases, and with Tanglu we want to make a distro which solves this. You might ask why we have to create a new distro for that, instead of creating improvements inside Debian? Creating a new distro allows us to do stuff we can never do in Debian. For example, we will include proprietary firmware in that distro, we will make installations of proprietary stuff possible easily (but don t ship with it by default) and we will have a time-based release cycle. These are already things which are a no-go for Debian, and that s fine. We don t want Debian to support these cases, as it is already a great distribution. We want to offer a distro as close to Debian as possible, but with a few modifications for use-cases which are not covered by Debian itself. Of course we will participate in DEX. If Debian Developers contribute to Tanglu, freezes will take even longer! This is an often-heard concern, it comes up on every mailinglist discussion about continuing development while freeze. I would disagree here, packaging new upstream stuff is not slowing down testing and improving of packages in Testing. Also, Tanglu is an offer for Debian developers to participate (we will sync privileges for their packages) we don t expect anyone to work on it, but as we think DDs know their packages best, we will make it possible for them to participate without extra barriers. We hope that Tanglu can add value to Debian and that Debian cycles can start with better-tested packages. You said you are a small team you cannot develop a whole distribution with it! Let s put that to the test! All people working on this are well aware of the issue that the project can not survive without much community-involvement on the long run. But we see a chance that many people are interested in it and that there is a high demand for it. At the beginning, we will just start with a small set of packages. We will also sync many packages from Ubuntu, to reduce workload. For example, it is planned to use the Ubuntu-Kernel and KDE packaging. By doing this, we keep the workload at the beginning low. We also reduce duplicate work with that. We even have some possible sponsors for the new distribution. But nothing is set in stone yet, so just wait for it to happen. Why not participate in Arch, OpenSUSE $other_distro? These are not Debian . I know, it sounds odd, but if you like the Debian way of doing things, you want to use a Debian-based distribution. There is nothing wrong with OpenSUSE. And Debian has issues too. But we want to be close to Debian and use it s tools and way of doing things. I hate you!!! You are doing it wrong!! The project is useless!
Well, that s fine. But there is no reason for hating us. If you dislike our idea, there are basically two options: First, you hate us but the project is successful. In that case, you have been wrong with hate, as there are definitely people who liked the project and contributed to it. Second, you hate us and we fail. In this case, there is no reason for hate, as the project will just vanish and you don t have to worry about it. So hating it would ve been just a big waste of energy. Also keep in mind that forking is a way to keep development healthy and to adapt software to new use-cases which it didn t target before. And we are not introducing incompatibilities here (like e.g. writing our own display server could). Instead, we want to stay close to Debian and reuse as much code as possible. Which desktop will you use? Everyone can add a new desktop to Tanglu, as long as the desktop-environment is present in Debian. Long term, we will have to offer Linux-newbies a default flavour, probably by setting a default download on the website. But as long as there is a community for a given desktop-environment, the desktop is considered as supported. At the beginning, we will focus on KDE, as many people have experience with it. But adding vanilla GNOME is planned too. Can you say something about the software used in Tanglu? Yes, but this is still in flow, so I can t promise final decisions here. On the server, side, we will try to use the Dak for repository management, as soon as we have enough server capacity. We will also use the standard Debian repository GUI and basically reuse most of the software there, to diverge less from Debian. The distribution itself will use a Linux Kernel from Ubuntu and systemd as the primary init system, as well as the login manager logind. It will be based on current Debian Testing with some fresh packages from Unstable and Experimental. We might also use the Ubuntu driver packages and KDE packaging. We expect to have a very rough start with the first release, but there will be enough time to polish Tanglu. Nice idea! How can I help? Well, you can help with basically anything at time from writing manuals, over designing logos and pages to administering a webserver and create packages. We are at an early stage of development at the moment, but we wanted to go public with it as soon as possible, to include the community and receive feedback so we can make that distro community-centric from the beginning. Most of the infrastructure is currently in progress too. So, if you want to get started with Tanglu, subscribe to our mailinglist tanglu-devel and write a mail to it, intruducing yourself. We can then include you in the loop. Generally, if you want to get access to our machines, a trusted GPG-signature will help a lot. If you want to talk to us, join #tanglu-devel or Freenode! Most discussions are currently happening there. And that s it! Tanglu will be awesome!

Some other projects of mine will develop a bit slower because I am now involved in Tanglu. But nothing will stop, and there is some pretty cool stuff coming for both GNOME and KDE (and I still have to implement DEP-11 for Debian).

Normally when using Subversion s SSH authentication facility you ll use your own SSH generated key-pair that svn will read from the proper location, usually $HOME/.ssh. However, there could be situations when you ll need to use a different key-pair. In such case you can use a nice trick to make svn+ssh authentication work smoothly. Let s say you have an external key-pair and the public key it s already set on the svn server. You store the private key somewhere in your home directory. Now when doing a svn checkout you ll find that you have to use SSH s -i parameter. However, when used together with svn it won t work as expected as you ll normally do when using ssh with an external key-pair. Subversion makes your life easier by using the $SVN_SSH environment variable, so you can put the ssh command and modifiers that fit your needs. In the external key case you can do something like:

export SVN_SSH="ssh -i </path/to/external-key>"

Next time you use svn s ssh auth it will read $SVN_SSH then use it. So now you can use svn commands such checkout, etc in the same fashion you normally do.

svn co svn+ssh://rudy@somesvnserver.at.somwhere.org/repo/for/software

Update: Jeff Epler offered great advice for using .ssh/config and key-pairs based on hostname. See the comments below.

I just received confirmation that my talk proposal for LOADays 2013 has been accepted. That means that for the fourth time in a row, I'll be speaking at LOADays. This time around, the talk will be about NBD: what is it, what does it, what can you do with it. I didn't consider that as an interesting subject at first; but after discussing the matter with someone else around the time I had to submit a proposal, he suggested I'd think about it... which made sense. So, all I have left to do now is to actually come up with an interesting talk. I'm sure that can be arranged.

Review: Higher Order Perl, by Mark Jason Dominus

Publisher:	Morgan Kaufmann
Copyright:	2005
ISBN:	1-55860-701-3
Format:	Trade paperback
Pages:	563

Disclaimer: The author and I both used to be (technically still are, but the newsgroup is dead) moderators of comp.lang.perl.moderated, and I knew him electronically from answering questions on the Perl Usenet newsgroups many years ago. Perl is, in general construction, a typical imperative language in the style of C, with object-oriented capabilities bolted (somewhat awkwardly) on. Most Perl code looks remarkably like C code with more powerful built-in data types and no memory management. A minority of Perl programs embrace object-oriented techniques and remind one of C++ or Java (or Python). But Perl also has powerful capabilities borrowed from functional programming languages and the Lisp tradition, even though many Perl programmers rarely use them and aren't familiar with them. Higher Order Perl focuses on those capabilities and how to use them effectively, starting with callbacks and uses of function pointers and moving into recursion and analysis of recursive functions, iterators, currying, and parsers. It concludes with a fully-worked example of constructing a declarative programming system using the techniques developed earlier in the book. Higher Order Perl is a programming book for an intermediate to advanced Perl programmer, already a rare topic. This is not a look at how to apply Perl to another area of programming, or a cookbook of techniques. It's an attempt to help a Perl programmer think about and use the language differently, and it follows through on that. It's refreshing and rare to read a programming technique book that's targeted at the practicing expert. (I think the size of the audience is often too small for publishers to target it.) Even the most experienced Perl programmer is probably going to learn something fundamental from this book, not just interesting trivia around the edges. On the negative side, though, I found the book a bit too focused on computer science and mathematics problems, particularly in the choice of examples and sample scripts. (And I say this as someone who has a master's degree in computer science with a software theory focus.) This is a bit hard to avoid for topics like recursion, where problems like computing Fibonacci numbers are classic, but throughout the book I struggled to focus past feelings of "but why would I ever do that"? The extended discussion of the Newton-Raphson method is the most memorable; I'm not sure that's a problem many Perl programmers would have and need a higher-order technique for. There's also a lot of discussion of recursion analysis and transformations between recursive and iterative expressions of problems, which is ground I remember well from my degree but which I've rarely had any practical use for in day-to-day programming. This is not a uniform problem, though, just a tendency. There are some great examples that I think are more in the mainstream of Perl problems, including a reinvention of File::Find that shows how to add more flexibility, a web spider, and a great discussion on how to construct a conventional queryable database on top of a flat file (a topic that's near and dear to my heart). And then there's the chapter on infinite streams. Dominus presents a method of using closures to create a version of an interator: a sort of infinite linked list that can keep generating additional elements. He presents this in several contexts, but one of them is log parsing, and that turned out to be exactly the solution that I needed for a problem I was working on while reading this book. I've written about this elsewhere, but this was a wonderful idea that helped me think about both Perl and a major application area in a completely new way, and I wrote an application using that knowledge that would have taken me much longer using different techniques and would have been much less fun. So, for me, this chapter was more than worth the entire book, and blankets the rest of it in a delighted feeling. Other people may or may not have that experience. I think it will depend on whether one of these techniques hits home for you the way that one did for me. This is a book with some idiosyncracies, and some sections that may drag. Having lots of fully-worked examples is a major plus, but some of those are so comprehensive that one can get a bit lost in the details. That particularly hit me with the last couple of chapters on parsing and on the example declarative programming application. Quite a bit of that text involved reinventing a recursive descent parser (another very computer science example), when I'm not quite sure why one wouldn't use one of the existing parser generators on CPAN for practical purposes, and inventing a lot of new syntax to try to make parser Perl code more readable. But one certainly can't complain that Dominus omits necessary details, and there is some appeal in watching an experienced programmer work through a problem from analysis to implementation. But, despite the idiosyncracies, I recommend this book to any experienced Perl programmer who wants to expand their view of the language. The techniques here closures, higher-order functions, iterators and streams, and formal parsers are powerful and underused in the Perl community. You may want to pick and choose which sections you pay close attention to, but I think everyone will find something of interest here. In the weeks since I read this book, my opinion of it has only grown. And I can't tell you just how much I loved the infinite stream concept. Rating: 8 out of 10

Last week I had another birthday, which was nice. I'm now all mature, and everything. Honest. I received a few surprise gifts from friends and strangers alike, which was pretty good. Other than that I didn't do too much. This weekend I'm going to be using "airbnb" to spend the weekend in Dundee with my partner who is regularly commuting between Edinburgh and Perth/Dundee, to work in various hospitals. With all the commuting time she's not had too much time to explore the actual city, and I've only been there once before so I'm sure it will be a fun weekend. The templer static site generator got a little bit of pimping on LWN.net the other day, thanks to Martin Michlmayr, although embarassingly I seem to have read the article and repeated the content in the conclusion, and duplicated that in my own comment. Ooops. Beyond that I've done little coding recently, although I suspect now that nodejs has had a stable release I might do something interesting soon. I don't want to dwell on the failure of Sim City - because I don't run windows and couldn't have tried it even if I wanted to - but I'm pondering the idea of a persistant grid-space where different items can be placed. I've not tried anything browser-based before, but the popularity of things like minecraft make me wonder if you had an "infinite grid" where folk could store "stuff", and scroll around in a browser you might be able to do interesting things. Starting small, with a 100x100 grid, and some kind of updated play-by-mail turfwars/drug-war like experience should be simple. But then again enthusiasm is easy to generate until you start working out how you'd interface with the server and what kind of client you'd need. Now to enjoy some 21 year old whisky and call it a night..

Today, during Blackhat Europe, Offensive Security announced the availability of Kali Linux 1.0, which aims to be the most advanced, robust, and stable penetration testing distribution to date. It is the successor of Backtrack Linux. Kali s choice of Debian Kali s release is a significant event in the security auditing and penetration testing field, and I m proud to see that Debian was retained as the best distribution to create this new product. Here s what Mati Aharoni of Offensive Security told me:

Debian provides a reliable base to build a new distribution and yet can easily be customized to add bleeding edge features, thanks to the unstable and experimental distributions.

Kali s development policies Even though Kali was prepared in secret, from now on Kali s development happens in the open in public git repositories. There are repositories for all the packages that have been created (or forked) as well as for the ISO images creation script. Debian packages are maintained with git-buildpackage, pristine-tar and the associated helper tools, making it easy to integrate the latest changes of Debian. Kali packaged several hundreds tools that relate to their field and they intend to contribute those which are DFSG-free back to Debian. Kali s technical infrastructure In the last year, I have been working within the Kali team to setup large parts of their infrastructure as a proper Debian derivative. Kali s main ISO images are built with live-build. All the bugfixes that I contributed to Debian Live were the direct result of my work for Kali. The git repositories are managed with gitolite. The package repositories are built with reprepro. The build daemons use rebuildd and sbuild. The (push) mirrors are synchronized with the same tools than Debian (based on rsync), but there s also a central server which redirects to a mirror close to you (and which is used by default everywhere). This one runs mirrorbrain (and not Rapha l Geissert s redirector). The ARM build daemons (armel/armhf) run on machines powered by Calxeda s Highbank (4 cores, 4 GB RAM) that work pretty well. Even better, Offensive Security is willing to dedicate one node of this cluster for Debian s own usage. The future This first release is not an end. It s only the start of a journey. Not all applications have been packaged yet and there s lot of work left to integrate everything in Debian. I m really looking forward to continue my collaboration with the Kali team as this has been one of the most interesting project I ever had as a Debian consultant. And also one of the few where I could really contribute something back to Debian.

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