For a while I've been wanting to tidy up some of my existing ikiwiki hacks, as well as test some changes I'd like to make to this site, but I hadn't had much success with setting up environments to play with it. That was until earlier in the year, when as a bit of an experiment I tried to put ikiwiki in docker. I've put up a preliminary image for anyone who is curious. It's in a very early state. When you start up the image, you get a HTTP daemon listening on port 8080 and serving a basic ikiwiki from /. A single administrative user is defined, user admin and password password. The CGI is set up (path /cgi) and websetup is enabled. The ikiwiki instance is configured with git as the vcs backend and the git HTTP backend is also enabled at path /git. It is set up for anonymous pull and HTTP basic authentication for push, with admin/password.

• Image: https://hub.docker.com/r/jmtd/ikiwiki
• Source: https://github.com/jmtd/debian-docker/tree/ikiwiki/ikiwiki

There's still a lot to do before this is useful for what I want to do with it, and I would strongly advise against using it for anything except testing yourself, unless you are going to layer on some changes (HTTPS and change the credentials at the very least!) but I thought I'd put it out there. If you have any suggestions for it, please either file an issue or leave a comment here. It's built on top of the stuff I mentioned last time but it should rebase on top of the "semi-official" Debian images without problems.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In September, 71.50 work hours have been dispatched among 7 paid contributors. Their reports are available:

• Ben Hutchings did 9 hours (out of the 14.5 hours that he had allocated, he will catch up in October).
• Guido G nther did 8 hours.
• Mike Gabriel did 16 hours (8 assigned + 8 remaining from month before).
• Rapha l Hertzog did 8 hours.
• Santiago Ruano Rinc n did 14.5 hours.
• Scott Kitterman did nothing out of the 4 hours allocated. He will catch up in October.
• Thorsten Alteholz did 14.50 hours.

Evolution of the situation October is back to the highest level of funding with 85.5 hours funded. The late sponsors have all caught up now. And next month will again rise to a new record with multiple sponsors having joined up. So far we already have two new silver sponsors (Universit Jean Monnet de Saint- tienne and Univention GmbH) and a new bronze sponsor (Entr ouvert). Many thanks to them! With those sponsors we crossed the 50% mark that was our first objective. \o/ But we still need more support to reach our second goal of funding the equivalent of a full time position. That said the increased level of support already allows us to do a better job in some areas that have been neglected : I asked the paid contributors to work towards providing mysql-5.5 in squeeze since version 5.1 is no longer supported by Oracle. We need beta testers to test the upgrade, see this message on the mailling list. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 15 packages awaiting an update (3 less than last month), the list of open vulnerabilities in Squeeze shows about 23 affected packages in total (7 less than last month). Thanks to our sponsors The new sponsors are in bold.

• Gold sponsors:
• The Positive Internet (for 16 months already)
• Blablacar (for 15 months already)
• Linode LLC (for 5 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 16 months already)
• Domeneshop AS (for 15 months already)
• Universit Lille 3 (for 15 months already)
• Trollweb Solutions (for 13 months already)
• Gandi SAS (for 10 months already)
• University of Luxembourg (for 7 months already)
• Rentabiliweb Group (for 5 months already)
• Univention GmbH
• Universit Jean Monnet de St Etienne
• Bronze sponsors:
• Offensive Security (for 16 months already)
• Seznam.cz, a.s. (for 16 months already)
• Evolix (for 15 months already)
• Freeside Internet Service (for 15 months already)
• MyTux (for 15 months already)
• Linuxhotel GmbH (for 13 months already)
• Intevation GmbH (for 12 months already)
• Daevel SARL (for 11 months already)
• FOSSter (for 11 months already)
• Bitfolk LTD (for 10 months already)
• Megaspace Internet Services GmbH (for 10 months already)
• Gree, Inc. (for 9 months already)
• Greenbone Networks GmbH (for 9 months already)
• NUMLOG (for 9 months already)
• WinGo AG (for 8 months already)
• Ecole Centrale de Nantes LHEEA (for 5 months already)
• Sig-I/O
• Entr ouvert

No comment Liked this article? Click here. My blog is Flattr-enabled.

A big update of all related packages (tex-common 6.04, texlive-bin 2015.20150524.37493-7, texlive-base/lang/extra package 2015.20151016-1) due to the move to support multi-arch. Of course, the regular updates of the TeX Live are included, too. With this change it should be possible to run a multi-arch system with only one TeX Live installed. Thanks to the excellent support and testing of the Multi-arch guys, in particular Thorsten Glaser, Helmut Grohne, Johannes Schauer, and Wookey, I learned a lot about multi-arch, and I hope that the current setup is safe. All the packages but the various lib* packages are tagged as Multi-Arch: foreign, while the lib packages are tagged Multi-Arch: same. Anyway, if you find a bug concerning multi-arch, that is that some of the programs exhibit architecture information, please let us know via a bug report. Updated packages acro, alegreya, amiri, assoccnt, attachfile, babel-french, babel-hungarian, barr, beebe, biblatex-philosophy, bidi, bnumexpr, caption, chemfig, chemformula, chemmacros, cjk-gs-integrate, csplain, dantelogo, dataref, dtxgen, dvipdfmx-def, dvips, eledmac, elements, fcolumn, fithesis, fontspec, genealogytree, gradstudentresume, gtl, jfontmaps, knuth-local, koma-script, kotex-oblivoir, kotex-plain, kotex-utf, kpathsea, l3build, l3experimental, l3kernel, l3packages, latex, latexconfig, ledmac, ltxfileinfo, lualatex-math, luamplib, luatex, luatexbase, luatexja, luatexko, make4ht, mcf2graph, mflogo, modiagram, multiexpand, newtx, odsfile, old-arrows, paracol, pdfpages, pdftex, plain, pst-stru, pxchfon, randomwalk, reledmac, resumecls, rubik, selnolig, showhyphens, siunitx, suftesi, tetex, teubner, tex4ebook, tex4ht, texlive-scripts, tikzsymbols, tipfr, tools, tudscr, uassign, unicode-math, unravel, visualfaq, xepersian, xetex-def, xint. New packages archaeologie, ctablestack, dynamicnumber, exercises, fibeamer, h2020proposal, imfellenglish, lstbayes, tempora, xellipsis. Enjoy.

Review: Ancillary Mercy, by Ann Leckie

Series:	Imperial Radch #3
Publisher:	Orbit
Copyright:	October 2015
ISBN:	0-316-24668-9
Format:	Trade paperback
Pages:	330

This is the third book of the series that starts with Ancillary Justice. Please don't read it out of order. The three books form a rare thing in SF: a trilogy with a clear start and a clear ending. They're ideally read fairly close together so that you can remember the people involved. By the end of Ancillary Sword, Leckie had apparently resolved most of the plot in the Athoek system, although the Ghost Gate and broader imperial turmoil still lurked. I was expecting this novel to be another change of scene, and probably a broadening of the scope into the more sweeping events set off by earlier books. That's not what Ancillary Mercy is at all. Leckie caught me by surprise early, and the book kept not going in the direction I was expecting. And the result is brilliant. It's obviously difficult to talk about this in detail, since there's no way I'm going to spoil this or any of the previous books. This is some of the best SF I've ever read, and I want anyone who's not read the series yet to have the full experience. What I will say is that there was a lot of character growth left, including in some places that I thought would remain setting-mandated blind spots. Leckie tackles some very tricky themes, ones that are hard to do well because of how thoroughly the ground has already been explored, and still manages to find an original take and an even more original tone. And remains true to Breq's characterization throughout, including one critical scene that's masterful in its heart-breaking understatedness. Breq's flat affect is both very difficult and incredibly rewarding as a first-person protagonist. If I had to call out one thing that makes this series so special to me, it's the way that Leckie puts the reader in the middle of a restrained and very careful culture, centers the book on a character with a very unusual relationship to emotion, nearly completely avoids outward displays of feeling, treats emotions primarily as data to be weighed with other information, and yet provides just the right amount of subtle clues and external reflection to show just how central emotion is to everything that happens. This is an incredibly difficult balancing act, much harder than an openly emotional book (let alone the tough-guy cliches that military SF is normally full of), and it makes the occasional pay-offs so rewarding. I think some people might find Ancillary Mercy too understated, but I thought it was note-perfect throughout. And the ending was spectacular. For those who are less enamored of Breq and more interested in the plot, don't worry: we do get some resolution to most of the loose threads. There's clearly potential in this universe for more stories (and apparently more books coming!), but this trilogy comes to a definite end. If I had to quibble, I'd say that a few bits of the plot are too convenient: the resolution would have been impossible without one very critical mistake at the start of the second book, and there's at least one perfectly-timed accident. But Leckie's most critical plot resolution tool was properly hung on the wall in the last book and used perfectly. It's hard to manage a satisfying resolution to a twisty political conflict between very sharp antagonists; for me, at least, Leckie pulls it off. Looking back on the whole series, I find it striking how much more satisfying and believable Leckie's military culture is for her setting than those I normally read. I think we're too often given far-future military stories that are full of impulsive drama, high emotion, and physical feats. But in a world of starships and space stations, advanced computers, careful and systematized roles, and precise engineering, that's not realistic. While there is some physical violence required, problems in that world are more likely to look like operational computer problems than gladiatorial problems. That means the required tools are careful and fast analytical skills, quick iterative decision-making, and precise execution, not physical toughness and grit. In that world, adrenaline is at best useless and often your enemy. Leckie's world of tea sets and emotional control is partly driven by other world-building factors, but, particularly in this book, I was struck by how well-adapted it is to a military where calm decisions and efficient follow-through are far more important than adrenaline-driven courage. The emotion is absolutely there, but the catharsis doesn't come through bloody battles or feats of physicality. Again, so tricky to pull off, since it plays against the expectations we bring as readers to a war story, but I found it so much more satisfying when written well. I also love that this series is not about saving the world, at least in any direct sense. It is about justice, and ethics, and about standing up for what's right, but it's just as much about identity, about how to choose and define one's ethics, and how to make the most of the small number of decisions one gets to make. Everyone in this world is operating under sharp constraints: culture, ability, available alliances, physical limitations, and particularly the role into which they were cast. Huge things happen in this series, but not from the dramatic, order-overturning action of Chosen Ones. Rather, change is created by individuals who find small points of leverage and definition, and who make quiet, critical decisions to become better people than they were. I adore this series, and particularly this conclusion, beyond all rational measure. I'm sure that won't be universal, just as other readers weren't as enamored as I was of the direction Leckie went in Ancillary Sword. But this was a series conclusion that I was not expecting at all, that kept surprising me right up to the climax, and was exactly the conclusion that I wanted. If you liked the previous books, and particularly if you liked Ancillary Sword but thought Breq was a bit too much in control of the plot and a bit too able to make things go her way, I think you'll love Ancillary Mercy. This is simply the best SF series I've read in a long time. Rating: 10 out of 10

Note: 2015/10/16: I need to add some links but I won t delay this more, posting now, will edit later. Summer ended long time ago, but believe me, I m still catching up with all the things that I began in June/July, all the things I left in August when I went holidays, and more things that appeared in August and September. This is a long overdue post, I hope you bear with me for waiting so long, and writing (now) so long too! June In June, I was 100% sure that I would not attend DebConf15 (well, I was 98% sure until then), and when the new Outreach Sponsorship grants were announced, I decided to write some mails to several Debian contributors, so they consider applying for the grant and attend DebConf (and maybe trigger some i18n/l10n meeting ). They kindly declined, and I understood their reasons, but also wondered what would have happened if the proposal would have come from somebody more official instead of a random contributor that they don t know. I also hoped that lots of other Debianites also write to newbies or not-yet-DD-contributors or non-packaging contributors to invite them to DebConf, and I hoped that they had better luck than me in convincing them :) July In July I usually work hard preparing the computer labs for next academic year at my workplace in the University, but I also have more free time in the long afternoons and evenings, since I don t sleep much, and there is not much to do outside with the summer hot. So I used that month to go on contributing to DebConf publicity and think a bit more about Debian and the other free software communities. I didn t put much time in advancing my selfhosting (no SSL yet in *.larjona.net! booooo!) but I decided to deep my toe in Sandstorm.io, and try to selfhost an instance ( http://lacaja.larjona.net ) and try Etherpad inside Sandstorm (since I failed in deploying Etherpad by myself in my jessie+nginx+postgres box). Sandstorm worked, and Etherpad was packaged in Sandstorm so it worked too; and I have my free-software-base pads now for writing and share. So I joined #sandstorm IRC channel since then, and there I learnt that Asheesh Laroia (who works in Sandstorm.io and is also a Debian Developer and was going to give a talk about Sandstorm.io in DebConf15) was offering mentorship for people wanting to learn Sandstorm packaging, and his proposal was to begin packaging Framadate. I also failed in selfhosting Dudle (prepared for Apache + FastCGI, couldn t make it work in my Nginx), so Asheesh s proposal looked suitable for me. We talked and decided to invest the rest of July and first days of August in learning to package Framadate. I learned a lot, but couldn t finish the task. I encountered many issues (setting my dev environment, and later trying to package), and we solved some of them but my time ran out. I posted my work in the list, and I hope that my feedback on the documentation and the issues I encountered helped Asheesh and the Sandstorm community. Framadate is packaged in Sandstorm.io now, Drew Fisher packaged it, not sure if my stuff was useful or not (it s been useful for me, for learning, at least). I ll talk more about Sandstorm.io in a future blog post updating on my selfhosting adventures. What I liked most was the kind of proposal of mentoring that Asheesh made. It was very detailed in every aspect: the task, the things you need to accomplish it, details about his availability for mentorship I try to be welcoming in the teams in which I participate, but the fact is that I fail in actually mentor, maybe because of not making specific proposals to people (until now, I was like Hi, newcomer! Go read this, this and this, and try for yourself any task you feel you like it, and come back if you have issues , la Debian ). This, plus the thoughts about my mails in June for diversity outreach in DebConf, made me feel the need of having a team where people willing to welcome newcomers share tricks and procedures, write together more specific proposals, and follow up the newcomers experiences in a regular way. I talked with Enrico Zini and we wrote down some notes for a Welcome Team in Debian; he said he would spread the word during DebCamp/DebConf and we would see what people thinks about it. August August came, and the day before going on holidays I was really tired: too much luggage to prepare, too many hours in front of the computer, and the usual stress of traveling; and I took the bad decision of signing some GPG keys of several Debianites that I met in July. I say bad decision because the lack of sleep showed its black magic and I accidentally deleted my secring.gpg file. I knew I had a backup but I didn t have too much time to invest and I didn t want to mess it with the backup too, and my laptop was going to stay at home, powered off, during the whole month, so I just went on holidays and left the GPG issue for later. The day after, meanwhile I was waiting in the airport for my boarding time, I received a mail accepting me as Debian Developer. Wow!! Really, I was not expecting that the process was already finished, I had interchanged several mails with my Application Manager (who happens to be the current DPL!) and I thought that his summer could be quite packed of Debian/DebConf work and my process could wait a bit. So it was a very happy news and very motivating after one month (July) full of free software work. On the other side, I was a bit scared: what type of Debian Developer are you, larjona, not capable to sign some GPG keys without breaking your setup?! but I answered myself well, I m the type of Debian Developer that has backups :) and then, with that mixed feelings of excitement and impostor syndrome, I took my plane and went on holidays, not expecting to touch any computer until the end of the month. August is probably the month in the year when I have more free time (holidays), but less time to dedicate to free software. I devote most of the month to visit family and stay with them, with no internet connection available or no free time to look at the mailbox or social networks or IRC But DebCamp and DebConf15 were happening during my holidays. And this DebConf15 was the first one in which I participated in the organization, and the first one in which I felt more than being a consumer of Debian videos . I could not follow the streamings, my only internet-capable device was my Android 2.x phone, but when I had wifi I fetched the mail, and during the nights, while everybody else was sleeping and I was laying on the terrace, below the sky full of stars, I could read batches of hundred of mails from debconf-discuss mailing list. And I could get some feeling from DebConf life, because I learned about the ad-hoc BoFs and discussions, the morning bike rides and swimming proposals, and the dancing classes, the i18m/l10n meeting, and many other things. I could answer some mail from time to time, and I also knew that a fellow Debianite from Madrid was going to bring me some stickers, maybe a t-shirt, and shake hands in my name to some persons. September and October September was about finishing reading all the mails and try to answer the pending ones, and preparing my computer to use my new Debian identity (and stop using larjona-guest). I still have some things to do, pending technical work, and some mails that I should have answered and I ve forgotten, for sure (if you sent me a mail that needs answer or would be fine that I answer (even if it was months ago!), please resend or ping me). I recovered my secring.gpg but and just now I added larjona@debian.org to the ID in my GPG key, but didn t signed the pending keys again (sorry dkg and holger! will catch up there soon). My subkeys expired and I m trying to find out how to proceed (they are in my FSFE SmartCard) :/ About the Debian teams, I ve resumed my work in publicity team (this year I ll try to be more involved, in Debian Project News in particular), partially in the website team, and recently I ve finished catching up with the Spanish translation of the website. I ve also joined the DebConf team again (for DebConf16, no matter I probably won t attend) and documented the Publicity task for DebConf, and I try to engage the mailing list and the IRC meetings. I finally could have time to watch some DebConf15 videos and Andreas Tille s talk ( Creating a more inviting environment for newcomers New experiences from MoM, SoB, Teammetrics ) helped me to step ahead in welcoming people with more useful stuff than Hi, newcomer! Go read this (general URLs), try for yourself whatever you like . I have made specific proposals for two people. In mid September I accepted an interview about Debian for a podcast with quite a lot audience (in Spanish), in which I explained the idea of the Welcome Team and offered myself as first-contact. Since then, two more people have contacted me and I have offered specific tasks I think are suitable for them. I also try to be more available in the IRC and offer some time spans for new contributors to DebConf to explain the git setup, the wiki, and all this stuff that looks more complicated than what it is. And I think that s all. My Debianite friend kindly brought me some stickers and a DebConf t-shirt, plus the organization t-shirt that the team gave me as present for my contributions in DebConf15. Neil McGovern kindly sent me a certificate of my new Debian Developer status (thanks!!), and it s posted in my wall at work. Here you are a photo! (Note: my wall is full of stickers and pieces of papers with things I need, things I like and things I use to explain my work (sometimes sarcastically/ironically ). Maybe some day I ll make a blog post about that!) I feel very proud and happy. Still, a lot of things to learn and work to do, but my intentions are: to keep on progressing (sometimes fast, sometimes slowly), never give up, and enjoy the multiple flowers I find in my way :) Thanks everybody! October and future Some other ideas/plans for the future (the ones I didn t say yet):

• Try to catch up with Debian Contributors development/news, adopt some data source (www.debian.org?), try to create some new data source (about translators, for example).
• Clean spam in the archive lists (now that I am DD I may help in not only Mark as spam , but actually remove the spam from the archive)
• Help in the review/updates of the Debian website (ongoing: /users; future: children-distros/derivatives, /partners).
• Try to get more involved in the Debian i18n team, at least in the part of internationalizing the Debian infrastructure (make translatable via PO files/templates many texts that used repetitively in the Debian website, for example) and in welcoming new members in translation teams or helping the weak ones (although I don t know many languages, the workflow and tools are common, so I think I could help new translators at least to get hands on the matter).
• Maybe some short screencasts/videos about the Debian infrastructure, for newcomers? (mailing lists, IRC, wiki, Alioth )

Comments? If you want to comment you can use this pump.io thread.
Filed under: My experiences and opinion, News Tagged: Communities, Contributing to libre software, Debian, Developer motivations, encryption, English, Free Software, gpg, libre software

I haven't had a blog for a few years now (and I might at some point be tempted to import all the old content), but occasionally I just want to point at something cool, rant about technology, or talk about my projects in the hope that someone else gets inspired to point at, or rant about them. My current interests are

• Debian (although I haven't done much in the last years),
• KiCad and PCB design,
• Hacklabs, the Maker movement, open hardware and democratization of production, and
• Software Defined Radio

Review: Firebird, by Jack McDevitt

Series:	Alex Benedict #6
Publisher:	Ace
Copyright:	November 2011
Printing:	October 2012
ISBN:	1-937007-80-4
Format:	Mass market
Pages:	357

Firebird is the sixth book in the Alex Benedict series about an antique hunter in the far future (albeit a far future that looks exactly like 1960s suburbia, but with spaceships). This is a very episodic series, though, and I don't think it would be hurt much by starting in the middle. There are references to earlier investigations, but they're fleeting, and I often didn't map them to remembered plots even though I've read the whole series to this point. The investigation in this book starts with the heir to an estate coming to Alex to sell some of the possessions of a physicist. Chase (Alex's assistant, and here, as in the last few books, the viewpoint character) doesn't even recognize the name, but Alex does: Christopher Robin disappeared forty-one years earlier, under circumstances that were never fully explained. He was also (and unusually for a physicist) interested in strange and marginal ideas: dark energy, new drive technology, parallel universes one could potentially cross into, and similar fringe concepts. The normal pattern of this series is that Alex will hear about some mystery, be unable to restrain his curiosity, and start poking around, usually turning up things that people would rather he didn't. It takes a while for that to happen here; instead, the story starts with Alex playing up popular interest in Robin's ideas in a rather mercenary attempt to increase the value of the estate. He stumbles into more mystery mostly by accident. Eventually he can't resist the allure of a revealed link between Christopher Robin and sightings of mysterious disappearing starships and the normal pattern kicks in, but he spends rather more of the book than normal being flippant and slightly unethical. I didn't much like the shift in tone. Alex is a lot harder to like this book, and not just for his business practices. His tone towards Chase also moves past the slightly superior smugness that's common to many books of this type (think Nero Wolfe) and well into condescending ass. Some of this may be intentional, as McDevitt uses this book to bring out a bit more of Alex and Chase's past and has some story reasons for making Alex less of a saint. But some of it feels accidental, or unnoticed, and it left a bad taste in my mouth. As with a lot of McDevitt, the actual mystery is slow, a bit scattered, and has a fair number of blind alleys. That property makes these books feel more like real investigations, but it works better when the characters are fully engaged in the investigation and are communicating a bit better than they are here. The plot also gets entangled in a subplot about a planet full of abandoned AIs, and while that was moderately interesting, it felt like an extended digression with dubious relevance to the main plot. McDevitt occasionally has trouble with plot focus, and I think I noticed more this time because the characters weren't as fun to spend time with. The end of Firebird was up to the usual standards of this series, albeit surprisingly traumatic. The rest of the book, though, felt markedly weaker. Alex decided to be obnoxious and play into his (previously mostly inaccurate) public perception as a money and glory hound. Chase seemed too flippant, uninterested, and a bit too much of a foil instead of a partner. And the plot felt like two different story ideas awkwardly smushed together. I think this was the weakest of the series to date. Hopefully the next book, which looks to be more of a direct sequel to this one, will improve. Followed by Coming Home. Rating: 6 out of 10

There are some things that I didn't mention in my sort-of quickly written entry about DebConf15. So first things first. When I received the mail about the room allocation I was at first confused. I was put into a room with other ladies, which I didn't expect. Granted, two of the other three names were people that knew me since a while, but it still felt like a mistake might have happened. But after a while I realized what has happened: It wasn't a mistake, it was intentional, I was finally recognized as woman for the room allocation too, which made me extremely happy. I was just just concerned about the third person who would be in our room who doesn't know me yet and whether it would make them feel uncomfortable. In the end, that was no trouble at all. I felt so empowered and more accepted than ever in this community. And when finally being on-site there another thing happened with me. I started to use the women's restroom. Up to now I usually had the feeling of "it's fine for me to use the male one, and I don't want other women to feel uncomfortable", but somehow, with a skirt on, it in the end made me feeling uncomfortable. Additionally, there were only three times in total when I used the male toilet (and one was on the boat for the daytrip), and every single time of it I felt extremely uncomfortable with it, like others might think I'm just faking it. It at least in my mind doesn't help with accepting me as female when I go to the male restroom. And it's not a Good choice! as a woman did put it during the conference dinner when there was a longer queue infront of the male restroom. It's not so much of a choice over here. But I give her the doubt of not knowing how important these little steps became to me over time. Totally unrelated to the restroom question but interestingly featuring it a fair bit I was made aware of the Assigned Male cartoon. I instantly fell in love with it, and in case you want to enlighten yourself a bit more about how some things you might say or do get received by trans people, be very much invited to read it. Sophie is currently on European tour with her book, unfortunately Vienna/Austria doesn't seem to be part of europe in that respect so I hope someone will be able to visit one of her stations to pick up a book for me ... And then there was also a small inofficial Nail Polish BoF going on at DebConf. I left it on my fingers for the next two weeks, totally in love with it. Unfortunately the nail polish I got for myself after DebConf had a rather big brush so I wasn't able to work on it, I failed miserably. ... which brings me to the empowerment that DebConf meant for me this year, and the time since. Given that I left the nail polish on I even took the comfort in being myself to go to work in my skirt on a more regular basis. Also, a very nice friend did visit me and we went lipstick shopping. I loved the color she chose, even though in the meantime it isn't visible enough for me and I guess I'll get another one rather sooner than later. Also, about what I mentioned in my last blog post was that my name change within the Debian project was granted. A quick update on that is that also now my GPG key got replaced. I guess it's finally time for me to write a gpg transition statement, even though I don't follow those myself. I still prefer meeting up with people face-to-face for signing their new keys. But given that it's called a transition statement makes it more appealing to me on that grounds. :) And I got invited to a local podcast show. Actually I know the person who does the podcast since several years already, he's also part of the local free software community who attends various events, and he does a podcast since several years now called Biertaucher (named after cooling the beer in a fountain). It is held in German language, so if you don't understand German you might want to skip these links.
In the first episode that I joined in I talked about DebConf. Afterwards we were sitting together and talking about that they would like to have more social topics too, not just technical things. So we took that chance and talked in Biertaucher #221 about Polyamory, which was a quite interesting experience. The host intentionally asked questions coming from a quite ignorant point of view, but it went nice. We were three poly people sharing our views and insight how it works for us.
Then there was Biertaucher #223 where it was just me and one of the hosts. We didn't had much to talk about from the past week, so we agreed to talk about Transgender in the end. Granted, it's mostly my personal story, but I guess I got some important topics addressed in a useful way. And, after getting my name changed in Debian, I thought about what it might take to get my name changed officially, too (as if it could get more official than using it throughout my work environment, both payed and voluntary, but ...). I covered that in the podcast, but mostly it is either quite expensive or requires me to change my gender in the register of births, which require a lot of other hassles that include psychiatry. Or, settle for a so-called "gender neutral" name as first name, which both doesn't sound very convincing somehow ... Only time can tell I guess. Guess that's enough for now, if I forgot something I might come back to it. :) One last note: I consider the Debian project a very welcoming one, and that can only work for a fair amount of people if the tone is right. So yes, I wholeheartly agree with the Code of Conduct. And I'm very disappointed to see that there are still people in the project that are advocating for a freedom of expression, so to say. Respectful communication with each other is a must in a bigger community to make it work, not something that might be a nice to have, and calling someone names and ridiculing them for stating that is absolutely not acceptable. I encourage those people to watch How to Throughly Offend and Insult People in Open Source presentation (or at least read the slides) that Gina Likins gave earlier this year. It might give them an idea why it's important to communicate respectful with each other, and that includes banning degrading terms like "SJW" from your vocabulary because it actually speaks a lot more about your own attitude than about the one of the person you use it for.

/personal permanent link Comments: 8 Flattr this

Two years ago, I discussed various ways of constructing a list in a Monad (or, more specifically, in IO) in Haskell, and compared their merits in terms of elegance, stack usage, number of traversals of the list and run-time efficiency. Recently, two blog posts discussed the issue further and proposed new, more daring alternatives. Neil Mitchell breaks through the abstraction provided by IO, duplicates the world and traverses the list twice, and obtains a speed-up for long lists. Twarn van Laarhoven went even further and wrote custom C-- code to destructively update the tail-pointer of the list cell to be able to create the list completely evaluated on the first start. This basically answers my question from two years ago:

I m still wondering: What would be required from Haskell, GHC or the monads in question to have a fully satisfactory solution here, i.e. one that is as fast as the naive recursion, as stack efficient as the difference list solution, and allocates no thunks, only list cells?

He also has a variant with a slightly nicer interface around holes , i.e. explicit objects on the heap that can later be replaced by indirections. Obviously, both approaches are very unsafe. I took this as an opportunity to redo my benchmark measurements, and include their variants (named escapeIO, hackIO and holeIO). The following table omits the variants with quadratic performance, as I ran it on longer lists now:

Variant	10^0	10^1	10^2	10^3	10^4	10^5	10^6
accumReverse	37ns	153ns	1134ns	12 s	208 s	8540 s	97ms
recursion	29ns	139ns	680ns	6790ns	160 s	6441 s	76ms
replicateM	26ns	126ns	677ns	6785ns	168 s	6314 s	78ms
accumDList	35ns	165ns	995ns	10 s	190 s	9706 s	100ms
streams	27ns	136ns	691ns	6788ns	173 s	5771 s	75ms
unsafeInterleave	60ns	329ns	2804ns	28 s	373 s	5605 s	57ms
listFix	51ns	412ns	4109ns	56 s	2761 s	42ms	445ms
escapeIO	41ns	187ns	1808ns	16 s	234 s	4409 s	45ms
hackIO	30ns	152ns	1199ns	11 s	140 s	3701 s	42ms
holeIO	40ns	222ns	1725ns	17 s	218 s	4446 s	53ms

The following graph shows that around 10000, the naive approaches become much slower and the fancy hacks pay of, with Twarn s tail-pointer-updating code performing the best: I would really like to see a package that provides a API like Twarn s holes, either in this raw unsafe variant (but with the garbage collector related code checked), or with a safe API using type hackery similar to the ST monad that ensures that after normal code gets its hands on a term possibly involving holes, the holes may no longer be modified. I have put the code and results on GitHub.

Now that the tsunami that followed my recent blog post has passed, I can read through all the nice comments and blogs of other people. I didn t expect that just writing up some links to posts on LKML, plus adding my personal opinion on what has happened and about my interpretation concerning Debian could gather so much attention. Anyway, let us look at the blog posts written in the aftermath. In particular do I want to answer to two blogs: Lars Wirzenius blog and Mart n Ferrari s blog, both of which are excellent examples of insults. I also want to mention that although the previous two are bad examples, there are fortunately also those who are able to resist primitive insults, in particular Gunnar Wolf (direct link to the blog does not work), and Miriam Ruiz blog, which contradict my blog and propose a different view, without pulling the knife. Lars Wirzenius Let us start with Lars (ah sorry, I have to call him Wirzenius here, strange custom has suddenly popped up in Debian!):

I think Preining mis-characterises what happens on the Linux kernel mailing list, and in Debian, in free software development in general, and what Sarah Sharp has said and done. I continue to think he is wrong about everything on this topic.

I am very surprised that Lars^WWirzenius is in possession of a crystal ball that allows him to see and evaluate my attitude towards all these items, considering that I have presented links to posts on the LKML, and yes, my interpretation of the matter. Mind that the whole text amounts to about 130 lines on my screen, while my personal opinion was stated in two paragraphs of total 9 lines plus some interspersed comments. And in these maybe 20 lines I didn t make general statements about open source, kernel development etc etc. Lars, I know you have closed your blog for comments so I couldn t ask you but please, can you send me one of your crystal balls if you have more of them? At least he has managed to keep a bit of proper writing and disagreed with my statement on Debian (whether there is fun or not in Debian). He is of course free to do that, but please, don t rob me the right to state that I think Debian has changed. All this dispute centers around people not being capable to distinguish two things: One, being against the Code of Conduct due to the inclusion of administrative actions without clear definitions, and Two, being pro offensive behavior and and insults. Now, dear Lars^WWirzenius, please listen: I never advocated abusive behavior or insults, nor do I defend it. (Did you hear that!) I simply opposed the Code of Conduct as ruling instrument. And what kind of emails I got due to my opposition was far outside the Code of Conduct you are so strongly defending. So please, stay at the facts, and stop insulting me. Thanks. Mart n Ferrari Concerning Mart n I don t have much to say but please, stop spreading lies. You stated:

Once again, he s complaining about how the fun from Debian has been lost because making sexist jokes, or treating other people like shit is not allowed any more.

Could you please come up with a reference to this? Or are you just interpreting? I am very disappointed about this level of discussion between Debian Developers. You not even cared to answer my comment on your blog. Should I say something clear here you should be happy that this has not been written on a Debian mailing list, otherwise I hope the Code of Conduct hammer would hit you.

---

So yes, it seems that at least these two blogs underline exactly what my opinion is: Communication culture in Debian has changed to be more company-like. Probably due to the ever increasing amount of developers that are paid for their work on Debian (Ubuntu), the pressure to follow US company codes has taken a firm grip, so firm that even stating my diverging opinion is already enough to get branded. Good Future!

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

• Niels Thykier uploaded debhelper/9.20151004 which exports SOURCE_DATE_EPOCH when running dh_auto_* (patch by Dhole). dh now also calls dh_strip_nondeterminism during build (patch by Andrew Ayer). The only remaining change regarding reproducibility in the custom debhelper is related to mtimes in data.tar which might be fixed directly in dpkg instead.
• Niels Thykier made another upload of debhelper/9.20151005 the next day to sort Build IDs added by dh_strip in control files.

Scott Kitterman fixed an issue with non-deterministic Depends generated by dh-python identified by Santiago Vila and Chris Lamb. Lunar updated the patch against dpkg which makes the order of files in control.tar.gz deterministic using the new --sort=name option available in GNU Tar 1.28. josch released sbuild version 0.66.0-1 with several fixes and improvements. The most notable one for reproducible builds is the new --build-path option and $build_path configuration variable added by akira which allows to explicitly chose a given build path. Reiner Herrmann wrote a new patch for dh-systemd to sort the list of unit files in the generated maintainer scripts. Packages fixed The following packages became reproducible due to changes in their build dependencies: aoeui, apron, camlmix, cudf, findlib, glpk-java, hawtjni, haxe, java-atk-wrapper, llvm-py, misery, mtasc, ocamldsort, optcomp, spamoracle. The following packages became reproducible after getting fixed:

• classified-ads/0.08-1 uploaded by Antti J rvinen, fix merged upstream, original patch by Reiner Herrmann.
• criu/1.7-3 uploaded by Salvatore Bonaccorso, original patch by Chris Lamb.
• doomsday/1.15.4-1 by Michael Gilbert.
• ejabberd/15.07-1~exp1 by Philipp Huebner.
• libxbean-java/4.4-1 by Emmanuel Bourg.
• markdown/1.0.1-8 uploaded by Matt Kraai, original patches by Chris Lamb (#776925) and akira (#793701).
• nedit/1:5.6a-3 by Paul Gevers.
• nvidia-settings/340.93-1 uploaded by Andreas Beckmann, original patch by Lunar.
• ocaml/4.02.3-2 by St phane Glondu.
• polygen/1.0.6.ds2-14 uploaded by Mehdi Dogguy, original patch by Chris Lamb.
• stsci.distutils/0.3.7-4 by Aurelien Jarno.
• vdr/2.2.0-4 by Tobias Grimm.
• vdr-plugin-xineliboutput/1.1.0+cvs20150907-3 by Tobias Grimm.
• w3c-markup-validator/1.3+dfsg-3 by Santiago Vila.
• xcolorsel/1.1a-19 by Santiago Vila.
• xmoto/0.5.11+dfsg-3 by Stephen Kitt.

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

• ognl/2.7.3-6 by Emmanuel Bourg.
• enblend-enfuse/4.1.4+dfsg-2 by Andreas Metzler.

Untested

• nvidia-xconfig/340.93-1 by Andreas Beckmann.
• nvidia-settings-legacy-304xx/304.128-1 by Andreas Beckmann.

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

• #801212 on unicode-data by Esa Peuha: set TZ=UTC when calling unzip.

reproducible.debian.net ProfitBricks once again increased their support for reproducible builds in Debian and in other free software projects by adding 58 new cores and 138 GiB of RAM to the already existing setup. Two new amd64 build nodes and 16 new amd64 build jobs have been added which doubles the build capacity per day and allows us to spot many kind of problems earlier. The size of the tmpfs where builds are performed has also been increased from 70 to 200 GiB on all amd64 build nodes. Huge thanks! When examining a package, a link now points to a table listing all previous recorded tests for the same package. (Mattia) The menu on the package pages has also been improved. (h01ger) Packages in the depwait state are now rescheduled automatically after five days. (h01ger) Links to documentation and other projects being tested have been made more visible on the landing page. (h01ger) To reduce noise on the team IRC channel five different types of notifications have been turned into mail notifications. The remaining ones have been shortened and the status changes have been limited to unstable and experimental. (h01ger) Maintainer notifications about status changes in a package will only be sent out once per day, and not on each status change. (h01ger) diffoscope development Some more experiments of concurrent processing have been made. None were good and reliable enough to be shared, though. Package reviews 48 reviews have been removed, 189 added and 23 updated this week. 9 FTBFS bugs were reported by Chris Lamb. Misc. h01ger met with Levente Polyak to discuss testing Arch Linux on Debian continuous test system with an easily extensible framework. The idea is to also allow testing of other distributions, and provide a nice package based view like the one for Debian.

Review: Magic's Price, by Mercedes Lackey

Series:	Last Herald Mage #3
Publisher:	DAW
Copyright:	July 1990
ISBN:	0-88677-426-8
Format:	Mass market
Pages:	351

Magic's Price is the conclusion of the Last Herald Mage trilogy (Lackey is from an era of fantasy in which trilogies stopped at three books), but those books are widely spaced and mostly stand alone. You might miss some context around Vanyel's personal life and the politics of the kingdom, but there's a lot of somewhat-awkward in-line summary, so you could read these books out of order if you wanted to. As with the previous two, this is a re-read of a book I've read several times before, but not for more than fifteen years. This is the book that finally introduces Stefan. On this re-read, that surprised me I thought of him as a large part of Vanyel's overall arc but he's only in the third book. He is, of course, key to the grand conclusion of Vanyel's story, beginning as the Bard who has the ability to blunt the pain of the badly-suffering king of Valdemar and then becoming more than that to Van. It's also a book about Vanyel trying desperately to hold things together as the country falls on hard times and far too much weight is put on his shoulders. And a book about a climactic fight against an arch-villain (awkwardly and retroactively inserted). And Vanyel coming to terms with his own foresight. It's a book about rather a lot of things, and therein lies a problem. I thought Magic's Promise had a better story than Magic's Pawn, but both had reasonably coherent stories and some internal flow. Magic's Price has three or four interwoven stories and some odd stops and starts. This is still early in Lackey's writing career (three years after her first novel), and I don't think she was entirely successful in what she was trying to do. The climaxes of the different stories don't quite line up and don't get enough separate attention, leaving a book that lacks clear dramatic shape, an engrossing build-up, or a satisfying climax. The biggest problem I had is that the main threat is not adequately supported. The story is building towards a rather drastic conclusion, one that has been foreshadowed from early in the series, but the threat that creates that conclusion comes out of nowhere. Lackey tries to tie it back to events from earlier in the series, and maybe it was planned all along, but there's little concrete support and no build-up. It feels like a retcon. And the key character in that threat receives almost no characterization whatsoever. I'm a bit grateful for that, since Lackey tends towards total evil in her villains, but to have the cause of all the drama in this story be a complete cipher takes a lot out of the story. (Also, I truly could have done without the rape.) The other irritation is that Vanyel spends quite a lot of the book being a jackass. This is another occasional problem with Lackey's books: her love stories, at least in her early books, involve a bit too much of people being stupid at each other. But I hadn't remembered just how much Van jerked Stef around and treated him miserably, straight to the end of the book. Love is a bit too ordained and imbued with magical powers in Valdemar, which is lucky for Vanyel: extensive plot support is required to explain why Stef didn't find someone else who was less of an ass. In the real world, when someone insists they have no emotional space for you, the correct reaction is "gotcha, have a nice life" and finding someone else to spend time with. This gets partly sorted out in the end, but I didn't find the reconciliation entirely believable, and certainly not fair to Stef. (And the age difference is just a little creepy, although thankfully Lackey doesn't put much focus on that.) On my first read of the Valdemar corpus, this was the book during which I started getting interested in the lore and politics of this universe. There's much more of that to come, thankfully, as I think it's my favorite part of the series. At this point in her writing career, Lackey is getting better at avoiding infodumps and making her magic system interesting. The politics is still a bit black and white, but the Tayledras are a lot of fun (and increasingly less like elves, even if that's the obvious initial inspiration), and the areas beyond Valdemar are developing some more coherence. The conclusion loses a lot from the lack of build-up and emotional support, but it still adds an interesting bit of magical history that will be important later. I wish I'd enjoyed Magic's Price more on re-read, but it was much spottier and more exasperating than I had remembered. That said, it certainly has its moments, particularly around the lore. This is the first book where one starts to realize just how powerful the Companions are, and just how much they're capable of that they're not showing. When I first read it, I loved it. Now, the flaws are too obvious, and Vanyel's behavior is too irritating, for me to unreservedly recommend it, but Magic's Price, and the whole trilogy, is important for building the lore of later books. When I get to Elspeth's part of the series, the politics and magical system will be developed at much greater length. Next, though, my favorite stories in this universe: Tarma and Kethry. Rating: 6 out of 10

We got pretty good feedback on Gnocchi so far, even if we only had little. Recently, in order to have a better feeling of where we were at, we wanted to know how fast (or slow) Gnocchi was. The early benchmarks that some of the Mirantis engineers ran last year showed pretty good signs. But a year later, it was time to get real numbers and have a good understanding of Gnocchi capacity. Benchmark tools The first thing I realized when starting that process, is that we were lacking of tools to run benchmarks. Therefore I started to write some benchmark tools in python-gnocchiclient, which provides a command line tool to interrogate Gnocchi. I added a few basic commands to measure metric performance, such as:
The command line tool supports the --verbose switch to have detailed progress report on the benchmark progression. So far it supports metric operations only, but that's the most interesting part of Gnocchi. Spinning up some hardware I got a couple of bare metal servers to test Gnocchi on. I dedicated the first one to Gnocchi, and used the second one as the benchmark client, plugged on the same network. Each server is made of 2 Intel Xeon E5-2609 v3 (12 cores in total) and 32 GB of RAM. That provides a lot of CPU to handle requests in parallel. Then I simply performed a basic RHEL 7 installation and ran devstack to spin up an installation of Gnocchi based on the master branch, disabling all of the others OpenStack components. I then tweaked the Apache httpd configuration to use the worker MPM and increased the maximum number of clients that can sent request simultaneously. I configured Gnocchi to use the PostsgreSQL indexer, as it's the recommended one, and the file storage driver, based on Carbonara (Gnocchi own storage engine). That means files were stored locally rather than in Ceph or Swift. Using the file driver is less scalable (you have to run on only one node or uses a technology like NFS to share the files), but it was good enough for this benchmark and to have some numbers and profiling the beast. The OpenStack Keystone authentication middleware was not enabled in this setup, as it would add some delay validating the authentication token. Metric CRUD operations Metric creation is pretty fast. I managed to attain 1500 metric/s created pretty easily. Deletion is now asynchronous, which means it's faster than in Gnocchi 1.2, but it's still slower than creation: 300 metric/s can be deleted. That does not sound like a huge issue since metric deletion is actually barely used in production. Retrieving metric information is also pretty fast and goes up to 800 metric/s. It'd be easy to achieve very higher throughput for this one, as it'd be easy to cache, but we didn't feel the need to implement it so far. Another important thing is that all of these numbers are constant and barely depends on the number of the metric already managed by Gnocchi.

Operation	Details	Rate
Create metric	Created 100k metrics in 77 seconds	1300 metric/s
Delete metric	Deleted 100k metrics in 190 seconds	524 metric/s
Show metric	Show a metric 100k times in 149 seconds	670 metric/s

Sending and getting measures Pushing measures into metrics is one of the hottest topic. Starting with Gnocchi 1.1, the measures pushed are treated asynchronously, which makes it much faster to push new measures. Getting new numbers on that feature was pretty interesting. The number of metric per second you can push depends on the batch size, meaning the number of actual measurements you send per call. The naive approach is to push 1 measure per call, and in that case, Gnocchi is able to handle around 600 measures/s. With a batch containing 100 measures, the number of calls per second goes down to 450, but since you push 100 measures each time, that means 45k measures per second pushed into Gnocchi! I've pushed the test further, inspired by the recent blog post of InfluxDB claiming to achieve 300k points per second with their new engine. I ran the same benchmark on the hardware I had, which is roughly two times smaller than the one they used. I achieved to push Gnocchi to a little more than 120k measurement per second. If I had same hardware as they used, I could interpolate the results to achieve almost 250k measures/s pushed. Obviously, you can't strictly compare Gnocchi and InfluxDB since they are not doing exactly the same thing, but it still looks way better than what I expected. Using smaller batch sizes of 1k or 2k improve the throughput further to around 125k measures/s.

Operation	Details	Rate
Push metric 5k	Push 5M measures with batch of 5k measures in 40 seconds	122k measures/s
Push metric 4k	Push 5M measures with batch of 4k measures in 40 seconds	125k measures/s
Push metric 3k	Push 5M measures with batch of 3k measures in 40 seconds	123k measures/s
Push metric 2k	Push 5M measures with batch of 2k measures in 41 seconds	121k measures/s
Push metric 1k	Push 5M measures with batch of 1k measures in 44 seconds	113k measures/s
Push metric 500	Push 5M measures with batch of 500 measures in 51 seconds	98k measures/s
Push metric 100	Push 5M measures with batch of 100 measures in 112 seconds	45k measures/s
Push metric 10	Push 5M measures with batch of 10 measures in 852 seconds	6k measures/s
Push metric 1	Push 500k measures with batch of 1 measure in 800 seconds	624 measures/s
Get measures	Push 43k measures of 1 metric	260k measures/s

What about getting measures? Well, it's actually pretty fast too. Retrieving a metric with 1 month of data with 1 minute interval (that's 43k points) takes less than 2 second. Though it's actually slower than what I expected. The reason seems to be that the JSON is 2 MB big and encoding it takes a lot of time for Python. I'll investigate that. Another point I discovered, is that by default Gnocchi returns all the datapoints for each granularities available for the asked period, which might double the size of the returned data for nothing if you don't need it. It'll be easy to add an option to the API to only retrieve what you need though! Once benchmarked, that meant I was able to retrieve 6 metric/s per second, which translates to around 260k measures/s. Metricd speed New measures that are pushed into Gnocchi are processed asynchronously by the gnocchi-metricd daemon. When doing the benchmarks above, I ran into a very interesting issue: sending 10k measures on a metric would make gnocchi-metricd uses up to 2 GB RAM and 120 % CPU for more than 10 minutes. After further investigation, I found that the naive approach we used to resample datapoints in Carbonara using Pandas was causing that. I reported a bug on Pandas and the upstream author was kind enough to provide a nice workaround, that I sent as a pull request to Pandas documentation. I wrote a fix for Gnocchi based on that, and started using it. Computing the standard aggregation methods set (std, count, 95pct, min, max, sum, median, mean) for 10k batches of 1 measure (worst case scenario) for one metric with 10k measures now takes only 20 seconds and uses 100 MB of RAM 45 faster. That means that in normal operations, where only a few new measures are processed, the operation of updating a metric only takes a few milliseconds. Awesome! Comparison with Ceilometer For comparison sake, I've quickly run some read operations benchmark in Ceilometer. I've fed it with one month of samples for 100 instances polled every minute. That represents roughly 4.3M samples injected, and that took a while almost 1 hour whereas it would have taken less than a minute in Gnocchi. Then I tried to retrieve some statistics in the same way that we provide them in Gnocchi, which mean aggregating them over a period of 60 seconds over a month.

Operation	Details	Rate
Read metric SQL	Read measures for 1 metric	2min 58s
Read metric MongoDB	Read measures for 1 metric	28s
Read metric Gnocchi	Read measures for 1 metric	2s

Obviously, Ceilometer is very slow. It has to look into 4M of samples to compute and return the result, which takes a lot of time. Whereas Gnocchi just has to fetch a file and pass it over. That also means that the more samples you have (so the more time you collect data and the more resources you have), slower Ceilometer will become. This is not a problem with Gnocchi, as I emphasized when I started designing it. Most Gnocchi operations are O(log R) where R is the number of metrics or resources, whereas most Ceilometer operations are O(log S) where S is the number of samples (measures). Since is R millions of time smaller than S, Gnocchi gets to be much faster. And what's even more interesting, is that Gnocchi is entirely scalable horizontally. Adding more Gnocchi servers (for the API and its background processing worker metricd) will multiply Gnocchi performances by the number of servers added. Improvements There are several things to improve in Gnocchi, such as splitting Carbonara archives to make them more efficient, especially from drivers such as Ceph and Swift. It's already on my plate, and I'm looking forwarding to working on that! And if you have any questions, feel free to shoot them in the comment section.

On the recently reviewed album International Sad Hits Vol 1 I wrote that Kim Doo Soo was the great surprise of the CD for me. So I went ahead and bought (not that easy, import from US!) one of his most recommended album, the Free Spirit. Sad songs, full of melancholy, speaking of desperation, isolation, destroyed love. The music and singing is simple, mainly based on guitar and voice only, at times harmonica, strings and others are added. In contrast to the Crying Philosopher Tomokawa Kazuki, the songs are all very melodic and easy to listen, but still carrying a strong impact. After listening to these songs, the melodies wander around my brain resonating again and again, like (mis)guiding lights in a dark forest. All the songs are in Korean, but fortunately the accompanying booklet carries a Japanese translation for the Korean incapables like me. In the future I will provide some translations into English, since I believe that this artist should be more known outside this small area. While a friend of mine said I don t like (bimbokusai) music, I have to say I enjoy reading through the sad stories while listening to this special music.

This is the 2002 fourth album by Korea s true cult folk/singer-songwriter hero, Kim Doo Soo. Kim Doo Soo is perhaps the deepest and most introspective of Korea s acid folk singers. Legends surround his songs political oppression, alcoholism, suicide, a 10-year period of mountain seclusion. [ ] On Free Spirit he mines productive veins of profound melancholy, animistic nature, and unfathomable, hermetic affection. These songs are couched in a veil of gorgeous, still melodicism, Kim s quavering vocals and guitar shaded with subtle accordion, cello, organ and harmonica. A reflective and unearthly masterpiece.
Forced Exposure

To this I cannot add anything more eloquent! The songs on this CD are as follows, the English translation is taken from Kim Doo Soo s official web page.

1. (Wild flower)
2. (Boat for the shore)
3. (Butterfly)
4. (Sweetbrier)
5. (Bohemian)
6. (Dawn rain)
7. 19 Blues (Blues of 19th street)
8. (Mountain)
9. (As time goes by)
10. Romantic Horizon
11. ( ) (Reminiscence)
12. (Evening river)
13. ( ) (Bohemian poetry)
14. , (Dandelion, dandelion)

My favorites under these songs are Boat for the shore ( You aren t coming any more onto a wild sea I am leaving ), Bohemian ( I m going to the shores of emptiness, my free spirit flows down the river probably his most famous song, assumed to be responsible for his retreat to the mountains), Dawn rain (A lovely song, and the only one without Japanese translation! Very strange.), Mountain ( Mountains Mountains my dream, mountains ). But I can recommend each and every song on this CD. To close this short review, if you are interested in something else but the usual happy-pappy KPop or JPop or USPop, and are searching for inspiring and songs with Tiefgang (deep meaning, as we say it in German), give this special artist a try! Some links concerning Kim Doo Soo that might be useful:

• Official Web site
• Kim Doo Soo Live Information for Japan
• A review of Kim Doo Soo s Bohemian at KPopStarz
• Kim Doo Soo at Psychedelic Folk with short reviews of his albums
• (in Russian) Biography of Kim Doo Soo on svyazalamuzyka

I m currently on the way home, returning from a four-day workshop for high school students; ages 13 to 20, grade 9 to 13. My goal was to teach them something about proofs and logic, in a ambitiously formal and abstract way. For this workshop, I created a computer program called The Incredible Proof Machine that allows the kids to explore creating a proof, by placing blocks on a canvas and drawing connections between them (see my previous blog post for an introduction). Subtracting time spent on on breaks, organizational stuff, the time the student needed to prepare a final presentation, I think we were working for a total of 14 hours, during which we covered propositional logic. I generally let the students explore and try to solve the tasks of one session mostly on their own, followed by a common discussion of what they have just done, what it means why it makes sense etc. The sessions were: assumptions and conclusions in general, with conjunction; implication; disjunction; falsum and tertium non datur. We also briefly discussed paper proofs with the student: how they look, and how they relate to the Proof Machine proofs. We had some lecture notes that we handed out pice-wise after each session. The sections were mildly¹ password-protected to avoid that the quicker students would work ahead, thus keeping the group together. One or two of the 13 students were doing very well and eventually, I gave them the passwords to the predicate logic section and let them work them on them on their own. The quickest managed to solve almost all of these as well, but (as far I as I can tell) without a deeper understanding of the quantifiers, and more a mechanical intuition. As expected, the students were able to solve most of the exercises, even when a proper understanding of the logical semantics was not yet fully developed. This was by design: I believe that this way it was more motivating and encouraging, as they could make it work , compared to a more traditional approach of first throwing a lot of theory at them and then expecting them to apply it. This was confirmed by their feedback after the workshop. I was happy with my implementation. The students immediately could work with it with very few hick-ups, and only one minor bug occurred², which I could fix on the spot. Having everything run on in the browser was a big plus, given that we had no stable internet connection for everyone: Once the Incredible Proof Machine was loaded, the student could continue to work offline. Personally, I find that the UI is occasionally too sluggish, especially on the weaker laptops, but it seems that the students did not seem to mind. Some students tried to connect outputs with outputs or inputs with inputs and the visualization did make it clearly visible that such a link is not actually connected to the block. The predicate logic part is a bit less convincing, with e.g. scoping of local constants not easily understood. I would say that this part would work better if some explanation is given before the students start working on the more involved rules. Our room was equipped with a smartboard, and I was delighted when I found out, mostly by accident, that I could actually use my finger to drag the blocks of the proof and to draw connections. This not only gave me a Minority Report -like feeling, but also meant that it was much easier for the students to follow my explanations when they could just watch my hand, instead of trying to locate the mouse pointer on a regular projector. I m generally doubtful whether such fancy technological toys are useful in the class room, but in this case at least I liked it. The ability to scribble anywhere on the screen was occasionally a plus as well. All in all I believe the Proof Machine was a useful tool, and I am sure that without it, it would have been tricky to have students voluntarily spend 14 hours on such a relatively dry and abstract topic. Given the amount of work that went into the development, I hope that this will not be the last occasion where it is put to good use. So if you have to teach formal logic and natural deduction-style proofs, you are welcome to use the Incredible Proof Machine to get your students excited. It is purely static, i.e. needs no special server-side infrastructure, and you can define your own logic (i.e. proof rules), sessions and tasks. Also, there are a few interesting way in which the Proof Machine could be extended. In particular, I d like it to be able to generate a normal , natural-language proof from a given proof even if it will sound a bit mechanical and then use hover-highlight effects to relate the formulas and sentences in the text proof to the connections and blocks in the graphical proof. Contributions are welcome!

Last night I saw Johnny Marr play at Newcastle University Student's Union. This is the first time I've been to a gig at the refurbished NUSU. I think the last gig I saw there was Nouvelle Vague in around 2007. It was a great gig! The accoustics in the Union are pretty good. I seem to recall they've always been pretty good. It used to be very cheap, too, which is sadly no longer true. Johnny Marr is an eminently likeable character. He did a set with a fairly balanced mix of his solo work from across two albums, Smiths songs and a few other bits and pieces, including a surprise cover of "Crash" by the Primitives, which by a seeming coincidence I had re-discovered a few weeks ago and can't stop listening to. The stand-out tracks for me were

• Speak Out Reach Out, from Playland
• Panic, by The Smiths (short but sweet, one of my favourite Smiths songs)
• New Town Velocity, From The Messenger
• Crash, by The Primitives

* Strikingly similar to Gary Numan's Metal. I think this must be intentional, because the guitar work at the end of the verses also sounds a lot like Numan's Complex, which is the track that immediately follows Metal on The Pleasure Principle. Speak Out Reach Out is a great song, and not just due to the similarity.)

One of the greatest pleasures of walking and hiking is to appreciate all of the many living things encountered along the way. A big part of that appreciation for me is to be able to identify individual species and learn the relationships among them. To that end, I would like to introduce a flashcard deck I created, based on the glossary of the excellent, and also free, Nova Scotia Plants, by Marian C. Munro, Ruth E. Newell, and Nicholas M. Hill, so that I could more effectively use the book as an amateur student of our local flora.

• Download the book.
• Download my Nova Scotia Plants glossary flashcard deck for Anki.
• Install Anki for your platform and register at ankiweb.net.
• Import the apkg deck file in Anki.
• Enjoy studying the plants of Nova Scotia with these resources.
• Comments are welcome here, and a review on ankiweb.net would be appreciated.

Creating the Nova Scotia Plants glossary for Anki I authored the deck on Debian, using the free software utility pdftotext (from poppler-utils), the small shell script below to produce a rough draft, and a text editor to clean up any errors, inconsistencies, and artefacts caused by the conversion process, such as descriptions which wrapped to a second line.

#!/bin/sh
pdftotext -f 40 -l 55 \
  'Print Nova Scotia Plants complete manuscript.pdf' \
  glossary_raw.txt
egrep -v '^[ixvl]+$' glossary_raw.txt   \
  grep -P '^\f?[ a-z]+'   \
  sed -re 's/^\f?([^ ]+)( [- ]+ ? [- ]+ )( ?(.+))/\1\t\4/' \
  > glossary_import.txt

Nova Scotia Plants The Anki flashcard deck is intended as a companion for studying Nova Scotia Plants, linked above, and available either as a single PDF file, or multiple, smaller PDFs per section or family. This ebook has been a constant companion to me on my tablet during my walks and to study in quiet moments of the day. It has enriched my enjoyment of nature in Nova Scotia immeasurably. I am indebted to the authors for the years of work they put into it, and for making it available to the public for free. I hope you get as much out of it as I have. Anki for devices One of the criteria I used in selecting Anki as my flashcard software is that it is available for Debian, but also should work on my devices. I use the free software, AnkiDroid, on my Android phone and tablet, available both in F-Droid and the Google Play store. I understand there is also AnkiMobile for iOS, but that is not free. Feedback Please take the time to give me feedback. I spent an afternoon and a morning putting these materials together to share, and am eager to hear if my work has benefited you. Let me know if you have any suggestions for improvements, and don t forget to leave a review at ankiweb.net.