Search Results: "ed"

3 September 2011

Gregor Herrmann: RC bugs 2011/21 - 2011/35

over 3 months without a posting about my RC bug squashing activities. that also means I hardly looked at any bugs in packages I'm not (co-)maintaining. anyway, here's the list of fixed RC bugs:

Benjamin Mako Hill: In Defense of Negativity

I often hear criticism of "negative campaigning" in the free software movement. For example, in reply to a blog post I once wrote about an FSF campaign, several people argued against, "negative campaigning of any sort, in any realm." Drawing an analogy to political smear campaigns, some members of the free software community have taken the position that negative campaigning in general is not useful and that negativity has no place in our advocacy. First, it is important to be clear on what we mean by a negative campaigns. I believe that there is a fundamental difference between speaking out against policies or actions and smear campaigns that employ untrue claims, ad hominem attacks, and that attempt to avoid a real conversation about issues. I will categorically condemn the latter form of smear campaigning in campaigns for software freedom or for anything else. That said, negativity directed at negativity has had a positive effect in many social movements. I have supported and participated in "negative" campaigns against proprietary software, software patents, DRM, centralized network services, and the firms behind these practices. I've done so because I believe that if one is taking an ethical position, it is justified, and often necessary, to not only speak about the benefits of freedom but against acts of dispossession and disenfranchisement. In some of the most effective social movements, unambiguously negative messages have been central. Should a campaign for abolishing child labor talk only about how valuable adult workers are to their employers or how happy kids are when they don't work? Should a campaign trying to abolish land mines talk only about the benefits of bomb-free fields and intact lower limbs? Should a free speech organization only speak out about the social welfare brought by a free press and never against acts of censorship? These may seem like outlandish comparisons but you can find people writing, only a couple centuries ago, about how slavery should be abolished by arguing in favor of the benefits of paid labor. Even if the economic arguments in favor of paid work are strong, these arguments seems irrelevant and offensive today. Whether slavery is more or less efficient is a moot point. Society has rejected it because it is wrong. We have made important strides toward eliminating injustices like child labor and slavery because activists waged decidedly negative campaigns against them and convinced others to join in opposition. In doing so, activists declared the status quo unconscionable and created an ethical responsibility to find alternatives and to redefine what was "realistic." While I will not suggest that the movement for software freedom is comparable in ethical weight to these other causes, I know that the free software mission is similar in kind. Of course, if one does not think that user control over technology is an ethical issue but is instead merely a matter of choice, one will probably oppose negative campaigns. It is also possible that a particular negative campaign is tactically unwise in that it is unlikely to reach a large audience, unlikely to change people's minds, or be difficult to carry out successfully. But such campaigns are a bad idea because they are ineffective, not because they are negative. Additionally, a movement that is purely negative and offers no reasonable alternative to the stated ill may also be unlikely to succeed. This is why, for example, I believe it is good that the FSF uses the large majority of its resources in the "positive" role of supporting free software. For those that do treat technological empowerment as an ethical ideal, it is both justified and essential to condemn the systematic disempowerment of others through non-free software just as we celebrate the benefits of software freedom. "Negative" campaigns against proprietary software, software patents, and DRM in music have already led our community to important -- if incomplete -- victories. The desire to right wrongs has been a critical part of our movement's success and of many others'. We would be wise not to give it up.

Tanguy Ortolo: Repacking ZIP-based containers

An open package showing two egg-like objects Several modern complex file formats are based on a ZIP container: this is at least the case of OpenDocument and EPUB. However, they are not simply a bunch of files joined into an archive, but they follow some rules in order to be easily recognized by tools such as file. As I had to unpack, modify and repack such a container, here is a recipe to do that.The zip command is flexible enough to allow you to work in place (I am not sure that it is really in place) to add, remove and replace files in the archive, however I find it more convenient to work on the unpacked tree and repack later. Unpack and work To unpack, just unzip, being aware that these containers do not have a root directory, so it is better to extract them to a dedicated directory. Modify as you wish; if you add, remove or replace files, remember that there is a file list to modify accordingly: META-INF/manifest.xml for OpenDocument, OEBPS/content.opf and possibly OEBPS/toc.ncx for EPUB. Repack To repack, you must create a ZIP archive without extra file attributes, and put the file mimetype uncompressed in first position. Its goal is to be visible as plain text at a fixed position, to serve as a magic file type indication. The remaining files can be stored compressed and in random order. For an EPUB, for instance, this gives the following commands: 
% zip --no-extra --compression-method store ../book.epub mimetype
% zip --recurse-paths ../book.epub META-INF OEBPS
This could be automated by a dedicated script, but I felt no need to write one yet. By the way, these options can be abbreviated as -X0 and -r.

Soeren Sonnenburg: Hello World

I have finally managed to setup a blog using handcrafted html and django. Having had the experience to write mloss.org, largescale.ml.tu-berlin.de and mldata.org my homepage here was done rather quickly (one weekend of hacking). If anyone is interested in website design I can really only recommend to use django. Work your way through the awesome tutorial or the book and get inspired by the sources of the many django based websites out there. Finally keep an eye on django code snippets that often contain small but useful functions and are solutions to problems you might have.

2 September 2011

Asheesh Laroia: Debian bug squashing party at SIPB, MIT


(Photo credit: Obey Arthur Liu; originally on Picasa, license.) Three weekends ago, I participated in a Debian bug squashing party. It was more fun than I had guessed! The event worked: we squashed bugs. Geoffrey Thomas (geofft) organized it as an event for MIT's student computing group, SIPB. In this post, I'll review the good parts and the bad. I'll conclude with beaming photos of my two mentees and talk about the bugs they fixed. So, the good:

The event was a success, but as always, there are some things that could have gone more smoothly. Here's that list: Still, it turned out well! I did three NMUs, corresponding to three patches submitted for release-critical bugs by my two mentees. Those mentees were: Jessica enjoying herself Jessica McKellar is a software engineer at Ksplice Oracle and a recent graduate of MIT's EECS program. She solved three release-critical bugs. This was her first direct contribution to Debian. In particular: Jessica has since gotten involved in the Twisted project's personal package archive. Toward the end of the sprint, she explained, "I like fixing bugs. I will totally come to the next bug squashing party." Noah grinning Noah Swartz is a recent graduate of Case Western Reserve University where he studied Mathematics and played Magic. He is an intern at the MIT Media Lab where he contributes to DoppelLab in Joe Paradiso's Responsive Environments group. This was definitely his first direct contribution to Debian. It was also one of the most intense command-line experiences he has had so far. Noah wasn't originally planning to come, but we were having lunch together before the hackathon, and I convinced him to join us. Noah fixed #625177, a fails-to-build-from-source (FTBFS) bug in nslint. The problem was that "-Wl" was instead written in all lowercase in the debian/rules file, as "-wl". Noah fixed that, making sure the package properly built in pbuilder, and then spent some quality time with lintian figuring out the right way to write a debian/changelog. That's a wrap! We'll hopefully have one again in a few months, and before that, I hope to write up a guide so that we run things even more smoothly next time.

Wouter Verhelst: Mind reading

As a spectator to sporting events, there are times when the ability to read a sport(wo)man's mind would be... interesting. For instance. Yesterday's woman's 1500m final at the world athletics championships in Daegu was won by Jennifer Simpson. This was a surprise to many, including (apparently) Jennifer herself, as evidenced by the look on her face after the finish. See, for instance, this youtube clip (interesting bits around the 4 minute mark) Alternatively, I'd love to know what went through Carlos Berlocq when he won his first game in the match against Novak Djokovic in the third set. I mean, obviously nobody expected the world number one to lose from a relatively unknown 74-ranked argentine player, but that doesn't make it less painful.

Raphaël Hertzog: Google plus and server to give away

Just a quick note to let you know that (like many free software hackers apparently) I have an account on Google+. I m not using it much yet but I like it in general. It s interesting to see how Google transformed Joindiaspora s aspects into circles . When Google will make an API available, I ll probably setup it like my public Facebook page so that new blog posts are automatically announced. In the mean time, it s going to be very quiet on my Google+ profile. That said, I used it twice this week: the first time because I m looking for a French developer with sysadmin skills, and the second time because I have a server to give away (Pentium IV 3Ghz, 4 Gb RAM, 200 Gb of diskspace in RAID1 Hard). If you take the server for a free software project, it can be hosted for free where it currently is (courtesy of Julien Danjou). So if you re also a Google+ user, feel free to add me to one of your circles.

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

Joey Hess: size of the git sha1 collision attack surface

The kernel.org compromise has people talking about the security of git's use of sha1. Talking about this is a good thing, I think, but there's a lot of smug "we're cryptographically secure" in the air that does not seem warranted coming from non-cryptographers like me. Two years ago I had a discussion on my blog about git and sha1, that reached similar conclusions to what I'm seeing here: It seems that current known sha1 attacks require somehow getting an ugly colliding binary file accepted into the repository in the first place. Hard to manage for peer reviewed source code. We all hate firmware in the kernel, so perhaps this is another reason it's bad. ;-) Etc. Well, not so fast. Git's exposure to sha1 collisions is broader than just files. Git also stores data for commits, and directory trees. Git's tree objects are interesting because they're a bag of bytes that is rarely if ever manually examined. If there was a way to exploit git such that it ignored some trailing garbage at the end of a tree object, then here's an attack injection vector that would be unlikely to be caught by peer review. If you can change the content of a tree without changing its sha1, you can simply make it link to an older version of a file that had an exploitable problem. Or you can assemble a combination of files that results in an new exploitable problem. (For example, suppose a buffer size was hardcoded in two files in the kernel, and then the size was changed in both -- make a tree that contains one change and not the other.) Now, git's tree-walk code, until 2008, mishandled malformed data by accessing memory outside the tree buffer. Was this an exploitable bug in git? I don't know. It is interesting that the fix, in 64cc1c0909949fa2866ad71ad2d1ab7ccaa673d9 relied on the parser stopping at a NULL -- great if you want to put some garbage after the tree's filename. With that said, the particular exploit I describe above probably won't work -- I tried! Here's all the code that stands between us and this exploit: 
        if (size < 24   buf[size - 21])
                die("corrupt tree file");
        path = get_mode(buf, &mode);
        if (!path   !*path)
                die("corrupt tree file");
Any good C programmer would recognise that this magic-constant-laden code needs to be careful about the size of the buffer. It's not as clear though, that it needs to be careful about consuming the entire contents of the buffer. And C programmers involved with git have gotten this code wrong before. tldr: If git is a castle, it was built just after cannons were invented, and we've had our fingers in our ears for several years as their power improved. Now the outer wall of sha1 is looking increasingly like one of straw, and we're down to a rather thin inner wall of C code.

1 September 2011

Sune Vuorela: First Plasma Active experience

John Layt recently blogged about his adventure with having children use Plasma Active with quite some success. The task I was this evening out at a board meeting in my local scout group, and for such a event you of course need the following I ve heard from various people that an iPad is great for such meetings, and produces much less paper waste, so of course, I wanted to try with my brand new Plasma Active tablet. Before meeting So before meeting: Charge tablet & fetch needed documents.
Possible issues: Everything was on a my imap server. Minutes was a plain text file, Agenda was a docx file, treasures report was a xls spreadsheet, and the various other papers were pdf files. For fetching, I ve heard a lot about Kontact Touch and everything using Akonadi. Besides me not being fully able to properly enter my password in the first 10 tries, and a sometimes flaky internet connection, everything here was a breeze. To the three first documents, the answer was Calligra Mobile . Rendered even the docx file better than libreoffice did. And Calligra Mobile was nice and touch friendly and worked pretty well for this. There is also something called Calligra Active , which is supposed to be way cooler, but still misses at least one essential feature to be used for a touchscreen only. It can only open documents passed to it on command line. And I m not yet very comfortable with a onscreen keyboard. For the last, there was Okular. The desktop edition of Okular. I was impressed by *how* usable Okular were for a touch screen device. A quick and dirty edition of a mobile Okular could probably be done with remove all toolbars and menubars and such and if no file is passed on command line, then open a file selector window and open selected file , which shouldn t take a person knowing the Okular code much time. But that s still just the Quick and dirty edition During And during the meeting, everything worked flawlessly, except the internet on site, so I was happy I had prepared in advance. As a extra bonus, Plasma Active offered the nice KDE Games, as John Layt also mentioned, for the parts of the meeting where it was a bit boring. So. At least for me and in this case, Plasma Active did its job, at least to a A. And it is still described as Alpha software. Issues There is, though, a few important usability issues: For QWidget based applications, oxygen s nice desktop feature of being able to move the application by dragging it from almost everywhere is just completely useless on a touch screen device when you are only using full screen applications. Luckily, oxygen-settings can disable this. Update: People tells me that this has already been fixed. The Network Manager Plasma Widget, in case of no network , is very hard to activate in order to select a network. A bit larger touch area here would be very nice. Currently, it feels like it is only slightly larger than a dot: . Future Oh boy, I m looking forward for Plasma Active getting to Beta or RC status. Or Final! And btw, I m looking for a job.

Matthew Garrett: The Android/GPL situation

There was another upsurge in discussion of Android GPL issues last month, triggered by couple of posts by Edward Naughton, followed by another by Florian Mueller. The central thrust is that section 4 of GPLv2 terminates your license on violation, and you need the copyright holders to grant you a new one. If they don't then you don't get to distribute any more copies of the code, even if you've now come into compliance. TLDR; most Android vendors are no longer permitted to distribute Linux.

I'll get to that shortly. There's a few other issues that could do with some clarification. The first is Naughton's insinuation that Google are violating the GPL due to Honeycomb being closed or their "license washing" of some headers. There's no evidence whatsoever that Google have failed to fulfil their GPL obligations in terms of providing source to anyone who received GPL-covered binaries from them. If anyone has some, please do get in touch. Some vendors do appear to be unwilling to hand over code for GPLed bits of Honeycomb. That's an issue with the vendors, not Google.

His second point is more interesting, but the summary is "Google took some GPLed header files and relicensed them under Apache 2.0, and they've taken some other people's GPLv2 code and put it under Apache 2.0 as well". As far as the headers go, there's probably not much to see here. The intent was to produce a set of headers for the C library by taking the kernel headers and removing the kernel-only components. The majority of what's left is just structure definitions and function prototypes, and is almost certainly not copyrightable. And remember that these are the headers that are distributed with the kernel and intended for consumption by userspace. If any of the remaining macros or inline functions are genuinely covered by the GPLv2, any userspace application including them would end up a derived work. This is clearly not the intention of the authors of the code. The risk to Google here is indistinguishable from zero.

How about the repurposing of other code? Naughton's most explicit description is:

For example, Android uses bootcharting logic, which uses the 'bootchartd' script provided by www.bootchart.org, but a C re-implementation that is directly compiled into our init program. The license that appears at www.bootchart.org is the GPLv2, not the Apache 2.0 license that Google claims for its implementation.

, but there's no indication that Google's reimplementation is a derived work of the GPLv2 original.

In summary: No sign that Google's violating the GPL.

Florian's post appears to be pretty much factually correct, other than this bit discussing the SFLC/Best Buy case:

I personally believe that intellectual property rights should usually be enforced against infringing publishers/manufacturers rather than mere resellers, but that's a separate issue.

The case in question was filed against Best Buy because Best Buy were manufacturing infringing devices. It was a set of own-brand Blu Ray players that incorporated Busybox. Best Buy were not a mere reseller.

Anyway. Back to the original point. Nobody appears to disagree that section 4 of the GPLv2 means that violating the license results in total termination of the license. The disagreement is over what happens next. Armijn Hemel, who has done various work on helping companies get back into compliance, believes that simply downloading a new copy of the code will result in a new license being granted, and that he's received legal advice that supports that. Bradley Kuhn disagrees. And the FSF seem to be on his side.

The relevant language in v2 is:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

The relevant language in v3 is:

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License

which is awfully similar. However, v3 follows that up with:

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

In other words, with v3 you get your license back providing you're in compliance. This doesn't mesh too well with the assumption that you can get a new license by downloading a new copy of the software. It seems pretty clear that the intent of GPLv2 was that the license termination was final and required explicit reinstatement.

So whose interpretation is correct? At this point we really don't know - the only people who've tried to use this aspect of the GPL are the SFLC, and as part of their settlements they've always reinstated permission to distribute Busybox. There's no clear legal precedent. Which makes things a little awkward.

It's not possible to absolutely say that many Android distributors no longer have the right to distribute Linux. But nor is it possible to absolutely say that they haven't lost that right. Any sufficiently motivated kernel copyright holder probably could engage in a pretty effective shakedown racket against Android vendors. Whether they will do remains to be seen, but honestly if I were an Android vendor I'd be worried. There's plenty of people out there who hold copyright over significant parts of the kernel. Would you really bet on all of them being individuals of extreme virtue?

comment count unavailable comments

Christian Perrier: Bug #640000

Brent S. Elmer reported the Debian bug #640000 on Thursday September 1st, against evolution. Bug #630000 was reported as of June 10th. This time, it took a little bit more than 2.5 months for 10,000 bugs. This #640000 bug was indeed "fixed" very quickly as it turns out it was not a bug..:-).. Congratulations to Corsac for fixing it..:-)

Niels Thykier: DEP-5, JW, dev docs and other goodies

Are you using DEP-5 in copyright file? Are you doing it right? Thanks to the work of Jakub Wilk, Lintian 2.5.3 will spot some of the regular mistakes (including syntax errors) and check if you are using the newest revision. This is far from the only thing Jakub Wilk has added to Lintian in this development cycle. Most of his contributions in 2.5.3 are listed next to a little [JW] in the changelog and I hope to see a lot more of those. :) Together with Jeremiah Foster, we have created a small POD document that hopefully will help aspiring developers. The file currently explains how the source code is divided, some core concepts and how to run specific tests in the test suite. The plan is to make it available on lintian.d.o along with a link to the git source code (#639974). Last time, I mentioned we have gotten rid of collection/fields by a simple improvement to our Lintian::Collect API. Turns out the same improvement could also be used on collection/source-control-file. This means we no longer create a file per field in the d/control of the source package. To avoid (any more) confusion, Lintian will now inform you if the package carries an override for a non-overridable tag (except if you use --quiet). On a related note, Lintian will now error out if it sees an unknown field in a vendor profile. Previously it would just silently ignore the field. There is one more change I would like to highlight and this one is probably best served with an example: 
$ lintian --show-overrides ../lintian_2.5.2.dsc
N: We build-depend on cdbs for the test suite
O: lintian source: unused-build-dependency-on-cdbs
N: We build-depend on quilt for the test suite
O: lintian source: quilt-build-dep-but-no-series-file
N: We don't have a patch system for lintian itself
O: lintian source: patch-system-but-no-source-readme
Lintian will now attempt to extract and print the comment related to the override from the overrides file. The comment will be printed above each tag the override applies to (so you may see some repeated comments). The full documentation for how Lintian finds the comments (or why it does not find the comment) is available in the Lintian User Manual. The exact format of the comments being outputted may change in the near future. Particularly, we may add a marker to assist the tools generating lintian.d.o to find the comments. Hopefully we will be able to close #512901 soon. Beyond the changes above, I am very happy to see the bug count drop below 180 unfixed bugs[1]. We have not been this low there since the 2.5.0~rc1 upload (in February) and I hope we can keep it this time. :) Finally if you ever wanted to run your own little lintian.d.o , then you may find the Lintian harness proposal interesting. The basic idea the is to clean up the current tools and make a proper frontend out of them. Should you be interested, feel free to come with suggestions or requests. [1] Lintain bug page I use the number next to Outstanding under Status near the bottom. So pending bugs are considered fixed in my numbering.

Lars Wirzenius: File copying and removal benchmarking

As part of my development of a backup application, I run benchmarks on it, and that means creating a test data set, running some backups, and then removing the test data set. One of the test data sets I use is a 140 gibibytes of my real data. The benchmark first copies the data to a temporary location. In other words, a fair bit of my current life is spent waiting for files to be copied and removed. The faster that goes, the better. Overnight, I ran a little benchmark on those operations, to compare a couple of ways to do them. The results are below: 
  elapsed  cmd
      (s)
    107.2  rm -rf tmp/data
     98.4  find tmp/data -delete
    100.1  find tmp/data -exec rm -rf   +
    116.2  find tmp/data -depth -print0   xargs -0 rm -rf
  elapsed  cmd
      (s)
   3567.5  cp -a tmp/data tmp/copy
   3219.5  cd tmp && mkdir copy && tar -C data -cf - .   tar -C copy -xf -
It is surprising, but it's clear that find is significantly faster than rm in deleting files, by almost ten percent. Since performance is a feature, this would indicate that that feature in rm is buggy. For file copying, the piping of two tars is a common trick, and it really is faster, again by almost ten percent. Obviously, there might also be a problem with the benchmark. I attach the script, which uses benchmark-cmd in extrautils, which I wrote for this kind of thing. If there is a problem with the benchmark, don't hesitate to provide a patch to fix that. There may be other ways to remove or copy files that should be compared, too. rsync? cpio? For file removal, a tool using Linux getdents directly would probably be faster than the portable code in GNU coreutils and findutils. Somebody should write that and compare. In all cases above, the test data set to be removed or copied is 30 GiB. Copies happened to the same disk (that's what happens with my backup benchmarks too). The filesystem used was ext4.

31 August 2011

Wouter Verhelst: Debian-installer support for NBD

Folkert asks, not without reason, whether my debian-installer support for NBD is available for testing. The answer is: yes, it is! At DebConf11 in Banja Luka, I sat down with Otavio, who helped me get the necessary modules uploaded in the correct way. As such, you can now install debian to an NBD device with a regular debian-installer build although for now, you'll probably still need a daily build to get it to work[1]. To test, you should do the following: And that's it! Everything else should Just Work(tm). Well, almost. There's some loose ends that I need to fix, which I haven't had the time to look into yet. Hopefully that won't take too long. [1] It's possible that cdimage builds will work too, but I haven't tested that.

Axel Beckert: Useful but Unknown Unix Tools: How wdiff and colordiff help to choose the right Swiss Army Knife

In light of the fact that it seems possible to fit the plastic caps of a Debian branded Swiss Army Knife (Last orders today!) on an existing Swiss Army Knife (German written howto as PDF), I started to think about which Victorinox Cybertool would be the best fitting for me. And because the Victorinox comparison page doesn t really show diffs, just columns with floating text which are not very helpful for generating diffs in your head, I used command line tools for that purpose: wdiff Because the floating texts are not line- but just whitespace-based, the tool of choice is not diff but wdiff, a word-based diff. It encloses additions and removals in + + and [- -] blocks. (No, those aren t Japanese smileys although they look a lot like some. ^^). The easiest and clearest way is to copy and paste the texts from Victorinox comparison page into some text files and compare them with wdiff:
$ wdiff cybertool34.txt cybertool41.txt
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher
So this already extracted the information which are the seven tools which are in the Cybertool 41, but not in the Cybertool 34. Nevertheless the diff is still not easily recognizable on the first glance. There are several ways to help here. First wdiff has an option --no-common (the according short option is -3) which just shows added and removed words: 
$ wdiff -3 cybertool34.txt cybertool41.txt
======================================================================
 +Schraubendreher 2.5mm,+ 
======================================================================
  +Holzs ge,+ 
======================================================================
  +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ 
======================================================================
  +Holzmeissel / Schaber,+ 
======================================================================
This is already way better to quickly recognize the actual differences. But if you still also want to see the common tools of the two knifes you need some visual help: One option is to use wdiff s --terminal (or short -t) option. Added words are then displayed inverse and removed words are shown underlined (background and foreground colors hardcoded as there is no invert colors style in CSS or HTML):

$ wdiff -t cybertool34.txt cybertool41.txt
Schraubendreher 2.5mm, Pinzette, N hahle mit Nadel hr, Holzs ge, Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ), Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Druckkugelschreiber, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), Holzmeissel / Schaber, Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher

But some still like to to use color instead of the contrast-rich inverse and the easily to oversee underlining. This is where colordiff comes into play: colordiff colordiff is like syntax highlighting for diffs on the command line. I works with classic and unified diffs as well as with wdiffs and debdiffs (the debdiff command is part of the devscripts package).
$ wdiff cybertool34.txt cybertool41.txt colordiff
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), Kombizange( H lsenpresser, Drahtschneider ), Stech-Bohrahle, Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), +Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, Schere, Korkenzieher, Zahnstocher $ wdiff cybertool29.txt cybertool41.txt colordiff
+Schraubendreher 2.5mm,+ Pinzette, N hahle mit Nadel hr, +Holzs ge,+ Bit-Schl ssel( 5 mm Innensechskant f r die D-SUB Steckverbinder, 4 mm Innensechskant f r Bits, Bit Phillips 0, Bit Phillips 1, Bit-Schlitzschrauben 4 mm, Bit Phillips 2, Bit Hex 4 mm, Bit Torx 8, Bit Torx 10, Bit Torx 15 ), +Kombizange( H lsenpresser, Drahtschneider ),+ Stech-Bohrahle, +Kugelschreiber( auch zum DIP-Switch verstellen ), Mehrzweckhaken (Pakettr ger), Metalls ge( Metallfeile, Nagelfeile, Nagelreiniger ),+ Dosen ffner( kleiner Schraubendreher ), Kleine Klinge, [-Druckkugelschreiber,-] Grosse Klinge, Ring, inox, Mini-Schraubendreher, Kapselheber( Schraubendreher, Drahtabisolierer ), +Holzmeissel / Schaber,+ Bit-Halter, Stecknadel, inox, +Schere,+ Korkenzieher, Zahnstocher
(Coloured Screenshots done with ANSI HTML Adapter from the package aha.) Some, especially those who are used to git, are probably confused by the default choice of diff colors. This is easily fixable by writing the following into you ~/.colordiffrc: 
newtext=green
oldtext=red
diffstuff=darkblue
cvsstuff=darkyellow
(See also /etc/colordiff for the defaults and hints.) colordiff has by the way two operating modes: So now let us compare the Cybertool 29 with Cybertool 34 in a normal diff (by using the texts from above and replacing all commata with newline characters) with git-like colors: 
$ colordiff cybertool29-lines.txt cybertool34-lines.txt
12a13,14
> Kombizange( H lsenpresser
> Drahtschneider )
13a16,17
> Kugelschreiber( auch zum DIP-Switch verstellen )
> Mehrzweckhaken (Pakettr ger)
16d19
< Druckkugelschreiber
25a29
> Schere
Or as unifed diff with some context: 
$ colordiff -u cybertool29-lines.txt cybertool34-lines.txt
--- cybertool29-lines.txt     2011-08-31 20:55:37.195546238 +0200
+++ cybertool34-lines.txt   2011-08-31 20:55:11.667710504 +0200
@@ -10,10 +10,13 @@
 Bit Torx 8
 Bit Torx 10
 Bit Torx 15 )
+Kombizange( H lsenpresser
+Drahtschneider )
 Stech-Bohrahle
+Kugelschreiber( auch zum DIP-Switch verstellen )
+Mehrzweckhaken (Pakettr ger)
 Dosen ffner( kleiner Schraubendreher )
 Kleine Klinge
-Druckkugelschreiber
 Grosse Klinge
 Ring
 inox
@@ -23,5 +26,6 @@
 Bit-Halter
 Stecknadel
 inox
+Schere
 Korkenzieher
 Zahnstocher
So if you want nicely colored diffs with Subversion like you re used to with git, you can use svn diff colordiff.

Tim Retout: Apache Request-Range headers

Note to self: when disabling Range headers in Apache to fix CVE-2011-3192, be sure to read the updated advisory and also disable Request-Range headers. (Presumably not "Range-Request" as in the summary of that link?) Or just apply the handy Debian update, of course.

Russell Coker: Links August 2011

Alex Steffen gave an interesting TED talk summarising the ways that greater urban density can reduce energy use while increasing our quality of life [1]. Geoffrey West gave an interesting TED talk about the way animals, corporations, and cities scale [2]. The main factor is the way that various variables scale in proportion to size. On a logarithmic graph the growth of a city shows a steady increase in both positive factors such as wages and inventions and in negative factors such as crime as it grows larger. So it seems that we need to decrease the crime rate significantly to permit the growth of larger cities and therefore gain more efficiency. The Mankind Project (MKP) has a mission of redefining mature masculinity for the 21st Century [3]. They have some interesting ideas. Phillip Zimbardo gave a provocative TED talk about the demise of men [4]. He provided little evidence to support his claims though.

Tollef Fog Heen: Bizarre slapd (and gnutls) failures

Just this morning, I was setting up TLS on a LDAP host, but slapd refused to start afterwards with a bizarre error message: 
TLS init def ctx failed: -207
The key and certificate was freshly generated using openssl on my laptop (running wheezy, so OpenSSL 1.0.0d-3). After a bit of googling, I discovered that -207 is gnutls-esque for "Base64 error". Of course, the key looks just fine and decodes fine using base64, openssl base64 and even gnutls's own certtool. Now, certtool also spits out what it considers the right base64 version of the key and I noticed it differed. Using the one certtool output seems to work, though, so if you ever run into this problem try running the key through certtool --infile foo.pem -k and use the base64 representation it outputs.

David Welton: Pranks that are actually funny

I saw this link on Hacker News:
http://techcrunch.com/2011/08/30/speaking-of-dropbox-heres-my-no-1-phone-prank/
And couldn't help but thinking it was singularly unfunny. He changed the guy's password - ha ha! I'm sure most people can do better. Here's one off the top of my head: I was due to leave a company in a few days, prior to our move to Austria. One of my colleagues in the programming department was tasked, in that period, with doing a bunch of work with Drupal, which he found singularly unpleasant and a pain in the neck to work with, which was compounded by the boss asking often about the status of the project. My colleague tended to be an early riser and would get into the office to get some work done early, before it got noisy and people started hassling him about this, that or the other thing. So on my soon-to-be-abandoned workstation, I set up a cron job that would, during those hours, randomly play a sound file I recorded while he was out, with my impression of a ghostly voice saying "druuuuuuuppaaaaaaallll". He said it scared the pants off him the first couple of times it went off.

Keith Packard: Altos1.0

AltOS 1.0 TeleMini support and a host of new features Bdale and I are pleased to announce the release of AltOS version 1.0. AltOS is the core of the software for all of the Altus Metrum products. It consists of cc1111-based microcontroller firmware and Java-based ground station software. AltOS Firmware TeleMini support, Kalman Filtering and more Support for the new TeleMini altimeter is included in version 1.0 along with a wealth of other new features: AltosUI New Features AltosUI has also seen quite a bit of work for the 1.0.1 release. Of course, many of the changes in AltosUI are to accomodate the new TeleMini altimeter and changes in the AltOS firmware for TeleMetrum. In addition, we ve also added lots of new features in response to user requests.

Next.

Previous.