The diffoscope maintainers are pleased to announce the release of diffoscope version 197. This version includes the following changes: You find out more by visiting the project homepage.

Passwords are used everywhere in our modern life. Between your email account and your bank card, a lot of critical security infrastructure relies on "something you know", a password. Yet there is little standard documentation on how to generate good passwords. There are some interesting possibilities for doing so; this article will look at what makes a good password and some tools that can be used to generate them. There is growing concern that our dependence on passwords poses a fundamental security flaw. For example, passwords rely on humans, who can be coerced to reveal secret information. Furthermore, passwords are "replayable": if your password is revealed or stolen, anyone can impersonate you to get access to your most critical assets. Therefore, major organizations are trying to move away from single password authentication. Google, for example, is enforcing two factor authentication for its employees and is considering abandoning passwords on phones as well, although we have yet to see that controversial change implemented. Yet passwords are still here and are likely to stick around for a long time until we figure out a better alternative. Note that in this article I use the word "password" instead of "PIN" or "passphrase", which all roughly mean the same thing: a small piece of text that users provide to prove their identity.

What makes a good password? A "good password" may mean different things to different people. I will assert that a good password has the following properties:

• high entropy: hard to guess for machines
• transferable: easy to communicate for humans or transfer across various protocols for computers
• memorable: easy to remember for humans

High entropy means that the password should be unpredictable to an attacker, for all practical purposes. It is tempting (and not uncommon) to choose a password based on something else that you know, but unfortunately those choices are likely to be guessable, no matter how "secret" you believe it is. Yes, with enough effort, an attacker can figure out your birthday, the name of your first lover, your mother's maiden name, where you were last summer, or other secrets people think they have. The only solution here is to use a password randomly generated with enough randomness or "entropy" that brute-forcing the password will be practically infeasible. Considering that a modern off-the-shelf graphics card can guess millions of passwords per second using freely available software like hashcat, the typical requirement of "8 characters" is not considered enough anymore. With proper hardware, a powerful rig can crack such passwords offline within about a day. Even though a recent US National Institute of Standards and Technology (NIST) draft still recommends a minimum of eight characters, we now more often hear recommendations of twelve characters or fourteen characters. A password should also be easily "transferable". Some characters, like & or !, have special meaning on the web or the shell and can wreak havoc when transferred. Certain software also has policies of refusing (or requiring!) some special characters exactly for that reason. Weird characters also make it harder for humans to communicate passwords across voice channels or different cultural backgrounds. In a more extreme example, the popular Signal software even resorted to using only digits to transfer key fingerprints. They outlined that numbers are "easy to localize" (as opposed to words, which are language-specific) and "visually distinct". But the critical piece is the "memorable" part: it is trivial to generate a random string of characters, but those passwords are hard for humans to remember. As xkcd noted, "through 20 years of effort, we've successfully trained everyone to use passwords that are hard for human to remember but easy for computers to guess". It explains how a series of words is a better password than a single word with some characters replaced. Obviously, you should not need to remember all passwords. Indeed, you may store some in password managers (which we'll look at in another article) or write them down in your wallet. In those cases, what you need is not a password, but something I would rather call a "token", or, as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a "high entropy, compact, and transferable string". Certain APIs are specifically crafted to use tokens. OAuth, for example, generates "access tokens" that are random strings that give access to services. But in our discussion, we'll use the term "token" in a broader sense. Notice how we removed the "memorable" property and added the "compact" one: we want to efficiently convert the most entropy into the shortest password possible, to work around possibly limiting password policies. For example, some bank cards only allow 5-digit security PINs and most web sites have an upper limit in the password length. The "compact" property applies less to "passwords" than tokens, because I assume that you will only use a password in select places: your password manager, SSH and OpenPGP keys, your computer login, and encryption keys. Everything else should be in a password manager. Those tools are generally under your control and should allow large enough passwords that the compact property is not particularly important.

Generating secure passwords We'll look now at how to generate a strong, transferable, and memorable password. These are most likely the passwords you will deal with most of the time, as security tokens used in other settings should actually never show up on screen: they should be copy-pasted or automatically typed in forms. The password generators described here are all operated from the command line. Password managers often have embedded password generators, but usually don't provide an easy way to generate a password for the vault itself. The previously mentioned xkcd cartoon is probably a common cultural reference in the security crowd and I often use it to explain how to choose a good passphrase. It turns out that someone actually implemented xkcd author Randall Munroe's suggestion into a program called xkcdpass:

    $ xkcdpass
    estop mixing edelweiss conduct rejoin flexitime

In verbose mode, it will show the actual entropy of the generated passphrase:

    $ xkcdpass -V
    The supplied word list is located at /usr/lib/python3/dist-packages/xkcdpass/static/default.txt.
    Your word list contains 38271 words, or 2^15.22 words.
    A 6 word password from this list will have roughly 91 (15.22 * 6) bits of entropy,
    assuming truly random word selection.
    estop mixing edelweiss conduct rejoin flexitime

Note that the above password has 91 bits of entropy, which is about what a fifteen-character password would have, if chosen at random from uppercase, lowercase, digits, and ten symbols:

    log2((26 + 26 + 10 + 10)^15) = approx. 92.548875

It's also interesting to note that this is closer to the entropy of a fifteen-letter base64 encoded password: since each character is six bits, you end up with 90 bits of entropy. xkcdpass is scriptable and easy to use. You can also customize the word list, separators, and so on with different command-line options. By default, xkcdpass uses the 2 of 12 word list from 12 dicts, which is not specifically geared toward password generation but has been curated for "common words" and words of different sizes. Another option is the diceware system. Diceware works by having a word list in which you look up words based on dice rolls. For example, rolling the five dice "1 4 2 1 4" would give the word "bilge". By rolling those dice five times, you generate a five word password that is both memorable and random. Since paper and dice do not seem to be popular anymore, someone wrote that as an actual program, aptly called diceware. It works in a similar fashion, except that passwords are not space separated by default:

    $ diceware
    AbateStripDummy16thThanBrock

Diceware can obviously change the output to look similar to xkcdpass, but can also accept actual dice rolls for those who do not trust their computer's entropy source:

    $ diceware -d ' ' -r realdice -w en_orig
    Please roll 5 dice (or a single dice 5 times).
    What number shows dice number 1? 4
    What number shows dice number 2? 2
    What number shows dice number 3? 6
    [...]
    Aspire O's Ester Court Born Pk

The diceware software ships with a few word lists, and the default list has been deliberately created for generating passwords. It is derived from the standard diceware list with additions from the SecureDrop project. Diceware ships with the EFF word list that has words chosen for better recognition, but it is not enabled by default, even though diceware recommends using it when generating passwords with dice. That is because the EFF list was added later on. The project is currently considering making the EFF list be the default. One disadvantage of diceware is that it doesn't actually show how much entropy the generated password has those interested need to compute it for themselves. The actual number depends on the word list: the default word list has 13 bits of entropy per word (since it is exactly 8192 words long), which means the default 6 word passwords have 78 bits of entropy:

    log2(8192) * 6 = 78

Both of these programs are rather new, having, for example, entered Debian only after the last stable release, so they may not be directly available for your distribution. The manual diceware method, of course, only needs a set of dice and a word list, so that is much more portable, and both the diceware and xkcdpass programs can be installed through pip. However, if this is all too complicated, you can take a look at Openwall's passwdqc, which is older and more widely available. It generates more memorable passphrases while at the same time allowing for better control over the level of entropy:

    $ pwqgen
    vest5Lyric8wake
    $ pwqgen random=78
    Theme9accord=milan8ninety9few

For some reason, passwdqc restricts the entropy of passwords between the bounds of 24 and 85 bits. That tool is also much less customizable than the other two: what you see here is pretty much what you get. The 4096-word list is also hardcoded in the C source code; it comes from a Usenet sci.crypt posting from 1997. A key feature of xkcdpass and diceware is that you can craft your own word list, which can make dictionary-based attacks harder. Indeed, with such word-based password generators, the only viable way to crack those passwords is to use dictionary attacks, because the password is so long that character-based exhaustive searches are not workable, since they would take centuries to complete. Changing from the default dictionary therefore brings some advantage against attackers. This may be yet another "security through obscurity" procedure, however: a naive approach may be to use a dictionary localized to your native language (for example, in my case, French), but that would deter only an attacker that doesn't do basic research about you, so that advantage is quickly lost to determined attackers. One should also note that the entropy of the password doesn't depend on which word list is chosen, only its length. Furthermore, a larger dictionary only expands the search space logarithmically; in other words, doubling the word-list length only adds a single bit of entropy. It is actually much better to add a word to your password than words to the word list that generates it.

Generating security tokens As mentioned before, most password managers feature a way to generate strong security tokens, with different policies (symbols or not, length, etc). In general, you should use your password manager's password-generation functionality to generate tokens for sites you visit. But how are those functionalities implemented and what can you do if your password manager (for example, Firefox's master password feature) does not actually generate passwords for you? pass, the standard UNIX password manager, delegates this task to the widely known pwgen program. It turns out that pwgen has a pretty bad track record for security issues, especially in the default "phoneme" mode, which generates non-uniformly distributed passwords. While pass uses the more "secure" -s mode, I figured it was worth removing that option to discourage the use of pwgen in the default mode. I made a trivial patch to pass so that it generates passwords correctly on its own. The gory details are in this email. It turns out that there are lots of ways to skin this particular cat. I was suggesting the following pipeline to generate the password:

    head -c $entropy /dev/random   base64   tr -d '\n='

The above command reads a certain number of bytes from the kernel (head -c $entropy /dev/random) encodes that using the base64 algorithm and strips out the trailing equal sign and newlines (for large passwords). This is what Gillmor described as a "high-entropy compact printable/transferable string". The priority, in this case, is to have a token that is as compact as possible with the given entropy, while at the same time using a character set that should cause as little trouble as possible on sites that restrict the characters you can use. Gillmor is a co-maintainer of the Assword password manager, which chose base64 because it is widely available and understood and only takes up 33% more space than the original 8-bit binary encoding. After a lengthy discussion, the pass maintainer, Jason A. Donenfeld, chose the following pipeline:

    read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)

The above is similar, except it uses tr to directly to read characters from the kernel, and selects a certain set of characters ($characters) that is defined earlier as consisting of [:alnum:] for letters and digits and [:graph:] for symbols, depending on the user's configuration. Then the read command extracts the chosen number of characters from the output and stores the result in the pass variable. A participant on the mailing list, Brian Candler, has argued that this wastes entropy as the use of tr discards bits from /dev/urandom with little gain in entropy when compared to base64. But in the end, the maintainer argued that reading "reading from /dev/urandom has no [effect] on /proc/sys/kernel/random/entropy_avail on Linux" and dismissed the objection. Another password manager, KeePass uses its own routines to generate tokens, but the procedure is the same: read from the kernel's entropy source (and user-generated sources in case of KeePass) and transform that data into a transferable string.

Conclusion While there are many aspects to password management, we have focused on different techniques for users and developers to generate secure but also usable passwords. Generating a strong yet memorable password is not a trivial problem as the security vulnerabilities of the pwgen software showed. Furthermore, left to their own devices, users will generate passwords that can be easily guessed by a skilled attacker, especially if they can profile the user. It is therefore essential we provide easy tools for users to generate strong passwords and encourage them to store secure tokens in password managers.

Note: this article first appeared in the Linux Weekly News.

Midsummer for me is also known as Noite do Lume Novo (literally New Fire Night ), one of the big calendar events of the year, marking the end of the school year and the beginning of summer. On this day, there are celebrations not very unlike the bonfires in the Guy Fawkes Night in England or Britain ^[1]. It is a bit different in that it is not a single event for the masses, more of a friends and neighbours thing, and that it lasts for a big chunk of the night (sometimes until morning). Perhaps for some people, or outside bigger towns or cities, Guy Fawkes Night is also celebrated in that way and that's why during the first days of November there are fireworks rocketing and cracking in the neighbourhoods all around. Like many other celebrations around the world involving bonfires, many of them also happening around the summer solstice, it is supposed to be a time of renewal of cycles, purification and keeping the evil spirits away; with rituals to that effect like jumping over the fire when the flames are not high and it is safe enough. So it was fitting that, in the middle of June (almost Midsummer in the northern hemisphere), I learnt that I was about to leave my now-previous job, which is a pretty big signal and precursor for renewal (and it might have something to do with purifying and keeping the evil away as well ;-) ). Whatever... But what does all of this have to do with aptitude or Debian, anyway? For one, it was a question of timing. While looking for a new job (and I am still at it), I had more spare time than usual. DebConf 15 @ Heidelberg was within sight, and for the first time circumstances allowed me to attend this event. It also coincided with the time when I re-gained access to commit to aptitude on the 19th of June. Which means Renewal. End of June was also the time of the announcement of the colossal GCC-5/C++11 ABI transition in Debian, that was scheduled to start on the 1st of August, just before the DebConf. Between 2 and 3 thousand source packages in Debian were affected by this transition, which a few months later is not yet finished (although the most important parts were completed by mid-end September). aptitude itself is written in C++, and depends on several libraries written in C++, like Boost, Xapian and SigC++. All of them had to be compiled with the new C++11 ABI of GCC-5, in unison and in a particular order, for aptitude to continue to work (and for minimal breakage). aptitude and some dependencies did not even compile straight away, so this transition meant that aptitude needed attention just to keep working. Having recently being awarded again with the Aptitude Hat, attending DebConf for the first time and sailing towards the Transition Maelstrom, it was a clear sign that Something Had to Be Done (to avoid the sideways looks and consequent shame at DebConf, if nothing else). Happily (or a bit unhappily for me, but let's pretend...), with the unexpected free time in my hands, I changed the plans that I had before re-gaining the Aptitude Hat (some of them involving Debian, but in other ways maybe I will post about that soon). In July I worked to fix the problems before the transition started, so aptitude would be (mostly) ready, or in the worst case broken only for a few days, while the chain of dependencies was rebuilt. But apart from the changes needed for the new GCC-5, it was decided at the last minute that Boost 1.55 would not be rebuilt with the new ABI, and that the only version with the new ABI would be 1.58 (which caused further breakage in aptitude, was added to experimental only a few days before, and was moved to unstable after the transition had started). Later, in the first days of the transition, aptitude was affected for a few days by breakage in the dependencies, due to not being compiled in sequence according to the transition levels (so with a mix of old and new ABI). With the critical intervention of Axel Beckert (abe / XTaran), things were not so bad as they could have been. He was busy testing and uploading in the critical days when I was enjoying a small holiday on my way to DebConf, with minimal internet access and communicating almost exclusively with him; and he promptly tended the complaints arriving in the Bug Tracking System and asked for rebuilds of the dependencies with the new ABI. He also brought the packaging up to shape, which had decayed a bit in the last few years. Gruesome Challenges But not all was solved yet, more storms were brewing and started to appear in the horizon, in the form of clouds of fire coming from nearby realms. The APT Deities, which had long ago spilled out their secret, inner challenge (just the initial paragraphs), were relentless. Moreover, they were present at Heidelberg in full force, in or close to their home grounds, and they were Marching Decidedly towards Victory: In the talk @ DebConf This APT has Super Cow Powers (video available), by David Kalnischkies, they told us about the niceties of apt 1.1 (still in experimental but hopefully coming to unstable soon), and they boasted about getting the lead in our arms race (should I say bugs race?) by a few open bug reports. This act of provocation further escalated the tensions. The fierce competition which had been going on for some time gained new heights. So much so that APT Deities and our team had to sit together in the outdoor areas of the venue and have many a weissbier together, while discussing and fixing bugs. But beneath the calm on the surface, and while pretending to keep good diplomatic relations, I knew that Something Had to Be Done, again. So I could only do one thing jump over the bonfire and Keep the Evil away, be that Keep Evil bugs Away or Keep Evil APT Deities Away from winning the challenge, or both. After returning from DebConf I continued to dedicate time to the project, more than a full time job in some weeks, and this is what happened in the last few months, summarised in another graph, showing the evolution of the BTS for aptitude: The numbers for apt right now (15th November 2015) are:

• 629 open (731 if counting all merged bugs independently)
• 0 Release Critical
• 275 (318 unmerged) with severity Important or Normal
• 354 (413 unmerged) with severity Minor or Wishlist
• 0 marked as Forwarded or Pending

The numbers for aptitude right now are:

• 488 (573 if counting all merged bugs independently)
• 1 Release Critical (but it is an artificial bug to keep it from migrating to testing)
• 197 (239 unmerged) with severity Important or Normal
• 271 (313 unmerged) with severity Minor or Wishlist
• 19 (20 unmerged) marked as Forwarded or Pending

The Aftermath As we can see, for the time being I could keep the Evil at bay, both in terms of bugs themselves and re-gaining the lead in the bugs race the Evil APT Deities were thwarted again in their efforts. ... More seriously, as most of you suspected, the graph above is not the whole truth, so I don't want to boast too much. A big part of the reduction in the number of bugs is because of merging duplicates, closing obsolete bugs, applying translations coming from multiple contributors, or simple fixes like typos and useful suggestions needing minor changes. Many of remaining problems are comparatively more difficult or time consuming that the ones addressed so far (except perhaps avoiding the immediate breakage of the transition, that took weeks to solve), and there are many important problems still there, chief among those is aptitude offering very poor solutions to resolve conflicts. Still, even the simplest of the changes takes effort, and triaging hundreds of bugs is not fun at all and mostly a thankless effort althought there is the occasionally kind soul that thanks you for handling a decade-old bug. If being subjected to the rigours of the BTS and reading and solving hundreds of bug reports is not Purification, I don't know what it is. Apart from the triaging, there were 118 bugs closed (or pending) due to changes made in the upstream part or the packaging in the last few months, and there are many changes that are not reflected in bugs closed (like most of the changes needed due to the C++11 ABI transition, bugs and problems fixed that had no report, and general rejuvenation or improvement of some parts of the code). How long this will last, I cannot know. I hope to find a job at some point, which obviously will reduce the time available to work on this. But in the meantime, for all aptitude users: Enjoy the fixes and new features! Notes [1] ^{^} Some visitors of the recent mini-DebConf @ Cambridge perhaps thought that the fireworks and throngs gathered were in honour of our mighty Universal Operating System, but sadly they were not. They might be, some day. In any case, the reports say that the visitors enjoyed the fireworks.

Review: Wakulla Springs, by Andy Duncan & Ellen Klages

Publisher:	Tor
Copyright:	October, 2013
ASIN:	B00EWZDPH4
Format:	Kindle
Pages:	99

This is another nominee for the 2014 Hugo Awards (for works published in 2013), this time in the novella category. In this case, though, I read the free ebook version from Tor (Macmillan) rather than the version from the voter packet, since I usually grab all the free ebooks of Tor.com stories. (Even if I'm quite behind in reading them, since I don't read much short fiction.) As an independently-published novella, it gets its own review in the book category. Wakulla Springs is the story of three generations (and four protagonists) who lived near or visited Wakulla Springs in the Florida panhandle. This is a real place: a huge freshwater springs and underwater cave system, now protected as a national park. Two of the four episodes in this story revolve around the filming of movies: a Tarzan movie and Creature from the Black Lagoon. This actually happened as well, although of course the story takes liberties with the details. This is also the story of race relations in the American deep south: the tense and uncertain interactions between black locals and rich white people, both locals and people from the film industry who came for a brief time and then left again. It's also a story about water, swimming, and the sense of being part of the water and knowing it well. This story doesn't develop any particular point; rather, it's more of a collection of character sketches, grabbing moments in time, glimpsing what it's like to cross racial barriers and to feel at home with one's choices. It's also, in a nicely subtle way, about encountering mythical creatures that are not part of one's world. To the locals, the film stars who visit Wakulla Springs are as wild and strange as the imagined creatures of the swamp, and in their way even more foreign. What this is not, though, is science fiction, or even fantasy. One of the complaints I'd heard about Wakulla Springs in the context of the Hugos was that it didn't qualify as a genre story. I'm usually inclined to dismiss these sorts of complaints, since they're often put forth by people with a far narrower definition of genre than mine. But, having read this story, I have to concur. It's very well-written and engaging, but it's not genre in any sense that I'd define it. There are some rare mentions of mythical creatures, but only in ways that are part of the setting, and which are no more fantastic than I'd expect from many mainstream stories. I'm a bit baffled why an SFF publisher would have bought it for an explicitly SFF forum; I have to assume that it's just because it's well-written and the authors have both written SFF. That said, even though this is not the sort of story I'd normally seek out, I'm still glad I read it. I thought the best part of the story was the first, which follows a black woman who takes a job at the Wakulla Springs resort during the filming of a Tarzan movie. The color lines are simply taken for granted by everyone, but Johnny Weissmuller comes off very well in his fictional representation and adds an enthusiastic energy that plays off well against the thoughtful care of the protagonist. The second part echoes this with a boy as the protagonist, but shifts a generation later. This means the color line is fought instead of simply assumed, although with limited success. I thought this part of the story had the best descriptions of the joy of swimming, and once again the movie folks bring a disruptive and positive change to the tightly-drawn lines of local roles and politics. The third and fourth parts I found slighter, elaborating on the story by showing the reader glimpses of the later life of the first two protagonists, but not, I thought, adding anything fundamental to the story. I'm not sure this would be satisfying if you were looking for a science fiction or fantasy story, but it's a solid mainstream story about race, class, and the joy of knowing and feeling a place. It captures an angle of Hollywood that I've rarely seen in movies: a disruptive and almost subversive playfulness and energy that doesn't fix problems but that does provide moments of escape from the realities of the world, even outside of the film. Worth reading, particularly since it's free. Rating: 7 out of 10

As a more or less random data point for DebConf13, here's the current bug stats for Debian. Hope to see you there, and if you want to attend the BoF Gitify ALL the things or the talk Gitify your life you can do so on site, via IRC in #vcs-home on OFTC, or simply follow the live streams. If you see my in person, I have two crates of Scheider Aventinus with me and don't plan on bringing home any full bottles. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1532
  • Affecting Jessie: 1019 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 832 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 51 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 38 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 743 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 187 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 187 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

Dear lazyweb, I'm encountering a routing problem on one of my Linux machine, for which I haven't found a solution so far. I have a machine which has several network interfaces in different network (it's our monitoring system). So I have eth0 with 192.168.1.2 and eth1 with 10.0.0.2, and an dns entry pointing from myname to 192.168.1.2. Problems occur, if hosts in the 10.x.x.x network try to access the hosts. Accessing it via it's IP address in that network works, however if they try to access him via his other IP address 192.168.1.2 (e.g. because they resolve it via dns), it leads to some problems: The host send their packet to his IP address (which works), however when my machine sends the answer, it takes a shortcut, and sends them directly via eth1 and with 10.0.0.2 as source IP. This however gets filtered by a (stateful) firewall somewhere in between, as packet send to 192.168.1.2 are suddenly answered by 10.0.0.2. So far I found two solutions: Adjust the DNS to resolve to different IPs depending on the source of the request (ugly) or tell all firewalls to always let packet from my host pass, despite the changes source IP (also ugly, and probably quite some work). Is there anything else I can do? What I would really like, would be a way to tell my linux box to always respond with the IP it was talked to, even if there would be a shorter way to the origin according to the routing rable. So, if a host 10.0.0.42 contacts my host via the IP 192.168.1.2, the answer packet should come from 192.168.1.2 via eth0 instead of instead of having a source IP set to 10.0.0.2, it should be send via eth1. Is that somehow possible? Update: Wow, that was fast! The ink of my blog is still fresh, and I already got the answer! The solution to my problem is policy based routing. Thanks to weasel, Peter and Dale for their pointers! More information available at http://lartc.org/howto/lartc.rpdb.html, http://www.itbuzzer.net/corner/2007/09/how-to-implement-source-routing-with.asp or http://wiki.georgweiss.de/Linux/source_routing.

Two years ago, I wrote about Elvera Voth and the power of love. Back then I wrote about her memories of seeing of service workers, who would be away from their home for 7 years at a time. Elvera remembered a gathering of people at the train station to see them off, and how they sang some German hymns at the occasion. Elvera s done a lot since, including starting an arts in prison program. And today, she hosted a hymn sing at the pump organ in the Friesen House parlor. The Friesen House is nearly 100 years old, and was on my parents property before it got moved to the Mennonite Heritage and Agricultural Museum. We were among maybe 20 people that showed up for the event. We walked in a few minutes early and Elvera was sitting at the organ already, along with a few other early arrivals. Many of the people there were over 70, and the moment we walked in, she said, Oh good! Another generation! And, of course, asked about us, where we live, who we are related to, etc. The announcement in our church bulletin said to bring a copy of Gesangbuch mit Noten if you have one. That was a common hymn book in Mennonite churches in Kansas (songbook with notes and yes, there was one without notes that had only words.) I pulled out my copy, and just opened it up. I saw my grandma s beautiful handwriting saying it belonged to Mr. and Mrs. R. A. Klassen . This I brought along, but was perhaps the only one. Elvera recognized it and was pleased to hear where it came from. We had a great time, and it turned out to feel like the kind of afternoon people around here used to have: time with friends and family visiting and maybe singing on occasion. After some introduction and some stories, we got to the singing and started with hymn #1 in the 1969 (English) Mennonite Hymnal. That song had German words below as well, which we sang: Grosser Gott, wir loben dich! (Holy God, We Praise Thy Name) Elvera played the organ while we all sang. And then we turned to #556, O Have You Not Heard. We read through the German lyrics (to help those that don t speak German):

Ich weiss einen Strom, dessen herrliche Flut
fliesst wunderbar stille durchs Land,
doch strahlet und gl nzt er wie feurige Glut,
wem ist dieses W sser bekannt? O Seele, ich bitte dich: Komm!
Und such diesen herrlichen Strom!
Sein Wasser fliesst frei und m chtiglich,
o glaub s, es fliesset f r dich!

Elvera translated this herself, a much more powerful translation than we usually get in English. And then we sang, this time a cappella. Elvera told the story about the train station to this group, and then, of course, we sang O Power of Love, one of the songs sung on that occasion. For that, she asked us to stand up and form a circle around the organ, and again we sang mostly a cappella. Singing that song with Elvera left few dry eyes in the room for sure. Someone brought up Nun Ist Sie Erschienen, and so of course we sang that. It wasn t in any hymnal, but I suspect we were the only ones there that didn t have it completely memorized. Elvera told us the story of the museum s pump organ; it had been in her family, and she had paid to have it restored and eventually donated it to the museum. It had been used every evening at twilight for singing and devotions in the family. She also told us that the singing at the Newton train station the same one our family uses a few times a year was what inspired her to a career of choral music. In the end, we probably spent more time visiting than singing, but that was just fine. Next the group went over to the Preparatory School, an old schoolhouse also on the museum grounds. There we had a traditional Faspa, an afternoon meal with coffee, Zwieback and jam, cheese, and various cookies. We all visited for awhile longer and then went on our way. It was a wonderful afternoon, and I hope to have a chance to do that sort of thing again.

Once there was a project called Debian and a Ganneff.... (unfortunately in German only....)

22:20 < cb> Das ist doch voll die Arbeit Maintainer zu werden :-). Ich geb
gew nschte Pakete immer nur weiter an einen der da sowieso schon den Kernel
betreut :-)
22:21 < Ganneff> es is nur viel arbeit wenn du keinen schimmer hast
22:22 < cb> ja ich hab nur das seepferdchen *g*
22:22 < Obilan> Knusper: ja sicher ist es das
22:22 < Knusper> kopf -> tisch
22:22 < cb> Knusper, wenn du die verwaisten pakete findest siehst du auf
der gleichen seite auch die links wie man maintainer wird
22:22 < Knusper> die hab ich gefunden
22:22 < cb> zumindest hab ich das das letzte mal dort gesehen
22:24 < Ganneff> wnpp?
22:24 < Knusper> aber man brauch dann schon leute, die einen "hoffieren"
22:26 < Ganneff> du brauchst erstmal die ahnung nen paket zu bauen.
22:26 < Ganneff> dazu siehe new maint guide
22:26 < Ganneff> dann brauchste nen sponsor. dazu gehe zur mentors liste
22:26 < Ganneff> dann machste mit dem eh weng rum (also normal so
paketuploads via dem)
22:26 < Ganneff> und hast da halt schon dein maintenance krams.
22:27 < Ganneff> irgendwann is der sponsor angekotzt von dir und dem
laufenden arbeit generieren
22:27 < Ganneff> der tritt dich dann dass du mal DM anf ngst.
22:27 < Ganneff> das machste dann, und jemand anders tritt dir deine pakete
als dmua zurecht, nachdem du in nem keyring irgendwo steckst.
22:27 < Ganneff> und dann kannste denn krampf selbst hochladen. aber nix
andres.
22:27 < Ganneff> irgendwann willste was andres. und willst das auch noch
ohne son doofen sponsor
22:28 < Ganneff> dann versuchste dich an DD
22:28 < Knusper> ahhhhhh
22:28 < Ganneff> dazu musste dir nen advocate suchen
22:28 < Ganneff> der is  blicherweise einer dem du vorher im prozess
laufend auf den wecker fielst
22:28 < Ganneff> und er deswegen den nm leutz sagt "oh gott, befreit mich
bloss von dem"
22:28 < Ganneff> die machen das dann, aber sie wollen dir mal etwas
schmerzen zur ckgeben
22:28 < Ganneff> desdewegen wirste viele fragen beantworten m ssen
22:29 < Ganneff> und wie beim t v das auto musste hier deine pakete nochmal
vorstellen und checken lassen
22:29 < Ganneff> und dann nochmal fragen beantworten
22:29 < Knusper> thx...
22:29 < Ganneff> irgendwann gehst du dann mit den antworten den nm leuten
so auf den geist dass die dem frontdesk sagen "meine kacke, den wolle mehr
nit mehr sehen, schickts den dochma zu den DAMs, die hamms verdient"
22:30 < Ganneff> und die machen das dann meist. ausser sie m gen dich nich.
dann darfste nochma fragen beantworten
22:30 < Ganneff> bei den dams darfste nur warten. die testen deine geduld
22:30 < Ganneff> irgendwann langweilen die sich aber
22:30 < Ganneff> und dann kriegste pl tzlich mail
22:30 < Ganneff> OH MEIN GOTT. EIN NEUER DD.
22:30 < Ganneff> ende
22:30 < Ganneff> kapitel 2:
22:30 < cb> sch ne beschreibung
22:30 < Ganneff> du machst ne zeit als dd rum
22:30 < Knusper> LOL
22:30 < Ganneff> votest durch die gegend
22:30 < Ganneff> l dst pakete umher
22:30 < Ganneff> machst bugs in stable
22:30 < Ganneff> gibts dem security team arbeit
22:31 < Ganneff> sprich - du gehst allen auf den sack. denn das is was ein
dd macht. muss ja schliesslich auch spass machen.
22:31 < Ganneff> aber irgendwann, also irgendwann, da wird das langweilig
22:31 < Ganneff> und dann verschwindeste mal ne zeit.
22:31 < Ganneff> weil du weisst - da gibts noch son team. das brauch auch
arbeit
22:31 < Ganneff> die suchen so leute die weggehen und sich verstecken
22:31 < Ganneff> nennt sich mia. die suchen.
22:31 < Ganneff> vielleicht finden die dich ja auch.
22:32 < Ganneff> dann kommste zur ck und machst mal wieder etwas arbeit f r
security/stable/sonstwen
22:32 < Ganneff> oder nicht, aber das is langweilig, da fliegste einfach.
22:32 < Ganneff> wennde dann gar keinen bock mehr hast und ne l ngre pause
willst
22:32 < Ganneff> dann gehste und machst eien auf emeritus
22:32 < Ganneff> das sind die rentner, die alten s cke, die sich
zur cklehnen und  ber die versuche der neuen lachen die sich grad von den
sponsoren qu len lassen
22:33 < Ganneff> ende kap. 2, ich hab keinen bock mehr. (jaja, emeritus)

Cheers to #debian.de on freenode

A new law is being made in germany, which will make consentual sex between minors a crime, which has to be punished with four years of prison at least, plus ending up in a sexual offenders database for life. I, for one, do not welcome our new taliban overlords.

These two articles explain the situation in full detail (in german).

In other news, it's 102 days until all electronic communication in germany (as in the EU) will be logged for half a year. (Until a terrorist attack happens which was planned for more than half a year...) This includes all emails sent, the location data of all mobile phones, every webpage visited and so on. From everybody. If you are in Berlin tomorrow, go demonstrate. I, for one, do not welcome George Orwells lack of imagination, 1984 looks really pale today. (But it's still a good read.)

My next blog post shall take place in teletubby land again and shall feature smileys as well. Sigh.

Auf den ersten fl chtigen Blick k nnte die Front genauso gut die R ckseite sein. Denn anders als die meisten Notebooks besitzt es vorne wie hinten eine sehr steil und pl tzlich abfallende Kante. Dank den Statusleuchten und Anschl ssen gestaltet sich das Finden der Vorderseite gl cklicherweise denkbar einfach.

Hier gefunden. Wenn man nicht weiss, was man schreiben soll, sollte man es vielleicht einfach lassen...