Dear Friends, I have shared a few times that I had a privileged childhood. I never had led a hand-to-mouth existence but more than that I was privileged to have made the acquaintance of Jaipur wale Mausaji while I was very young. I have been called miserly by my cousin sisters whenever they write letters to me and I don t answer simply because whatever I feel for them, words feel inadequate and meaningless. The same thing applies in this as well. I am sharing few bits here as there are too many memories of a golden past which will not let me go till I have shared a few of them. First let me start by sharing the relation I had with him. By relation he was my mother s-sister s husband. In English, he would probably be termed as Maternal Uncle although he was much more than that. My one of the first remembrances of him was during Madhu Didi s Shaadi (marriage). Madhu Didi is uncle s daughter and I would have been a impish 4-5 year old at the time. This was the first time I was gonna be part of The Great North Indian Wedding and I didn t know what was in store for me as I had grown in Pune. I remember finishing my semester tests and mummy taking me to Pune Station. I was just excited that I would be travelling somewhere and had no clue what would be happening. We landed in Agra, took another train and landed in Jaipur in the middle of the night at their home at Sangram Colony. While I had known few of the cousins, I was stumped to see so many cousins jumping out of everywhere. The look on my face was one of stupefaction and surprise . The only thing which would closely resemble that would be Bilbo s 111st Birthday party in Lord of the Rings (Part 1). In fact, by a curious quirk/twist of fate, I came to know of a Naniji or somebody like that who by relation was far elder to me, while she was either my age or below my age. As was customary, had to bow down sheepishly. As a somewhat alone boy, to be thrown in this rambunctious bunch and be the babe in the woods, I was quickly chopped and eaten up but had no complaints. I would get into trouble onto a drop of a hat. While Mausiji would threaten me, Mausaji would almost always defend me. While Mausiji could see through me, the twinkle in Mausaji s eyes used to tell me that while he knew what I was upto, for reasons unknown, he would always defend me. Mausaji s Sangram Colony s house became my cricket ground, football ground and all and any ground to play and be. Mausaji and his brothers used to live near each other and the lane they had, had hardly any vehicles on it, so all the cousins could play all they want with me being the longest, perhaps unconsciously trying either to make for lost time or knowing/unknowing this was too good to last. Today s Pokemon generation might not be able to get it but that s alright. They also had a beautiful garden where Mausiji used to grow vegetables. While playing, we sometimes used to hurt her veggies (unconsciously) or just have shower with the garden hose. Mausaji used to enjoy seeing our antics. One of the relatives even had a dog who used to join in the fun sometimes. When mummy and Mausiji expressed concern about the dog biting, Mausaji would gently brush it aside. One of the other things in Didi s marriage is we got a whole lot of sweets. While Mausiji tried to keep us in check with sweets, both Manish Bhaiya and Mausaji used to secrete sweets from time to time. When I was hungry and used to steal food (can t wait till the appointed time) either Bhaiya or Mausaji would help me with the condition I would have to take the blame if and when we got caught as we invariably did. Mausaji s house had a basement where all the secreted sweets and food used to get in. Both me and Manish Bhaiya would be there and we would have a riot in ourselves. We would enjoy the adrenaline when we were stealing the food. As I was pretty young, I was crazy about the Tom and Jerry cartoons that used to come on Television that time. I and Bhaiya used to act like Jerry and/or his cronies while Mausiji would invariably be the Tom with Mausaji all-knowing about it but acting as a mere bystander. I remember him egging me for many of the antics I would do and get in trouble in but as shared would also be defended by him. The basement was also when I was becoming a teenager where Manish Bhaiya showed me his collection and we had a heart-to-heart about birds and bees. While whatever little I had known till that time was from school-friends and my peers at school and I didn t know what was right or wrong. Bhaiya clarified lot of things, concepts which I was either clueless or confused about. When I look back now, it is possible that Mausaji might have instructed Bhaiya to be my tutor as I used to be somewhat angry and lash out by the confusing times. As we used to go there for part of holidays, I remember doing all sorts of antics to make sure I would get an extra day, an extra hour to be there. I never used to understand why we had to go to meet the other relatives when all the fun I could have was right there only, couldn t Mummy know/see that I used to enjoy the most here. Mausaji was a clothier as we understand the term today and a gentleman to the core. He was the co-owner of Rajputana Cloth Store in Jaipur. Many VIP s as well as regular people used to visit him for getting clothes designed and stitched under his watchful eyes. I never saw him raise his voice against any of the personnel working under him and used to be a thorough gentleman to one and all. Later, as I grew up I came to know and see that people would phone up and just ask him to do the needful. He would get the right cloth, stitch it right and people used to trust him for that. He was such an expert on cloth and type of clothes, that by mere touch he could talk/share about what sort of cloth it is. One of his passions was driving and from the money he had saved, he had got an Ambassador Car. Every day or every other day or whenever he felt like it, he used to take either the gang or me with mummy or me with anybody else. Each ride used to be an adventure in itself, with a start beginning and an end. I always used to watch out for the car-rides as I knew we would get sweets or something as well as he would regale us with stories about a place here and there. There was a childlike curiosity and interest in him which was infectious to one and all. The only weakness that he had was he liked to drink wine once in a while. When I was a kid, I was never able to give him company, only few years back, for the first time I was able to share wine with him which was also a memory I treasure. Those who know him closely knew the many up and downs that he went through, but as a gentleman he never let on the hurts he had or didn t curse his fate or anything else that we do when things go bad from our perspective. While there is much to write about him, it will not accomplish anything that is not known about him. I ll add with the private joke that was between him and me. When I was little, I used to call him Mausaji, Samosaji for a) I liked Samosa and b) Samosa has a bit thick skin outside and underneath it s all gravy. In reality though, he was butter all the way. I miss you Mausaji and wish I could turn the clock back and come with Mummy to visit both Mausiji and you. I hope your new journey takes you to even further heights than this life. Savouring the memories mummy and I, hope we meet you again in some new Avataar
Filed under: Miscellenous Tagged: #antics, #growing up, #holidays, #Manish Bhiaya, #Mausaji, #Sangram Colony

Review: Queen of Sorcery, by David Eddings

Series:	The Belgariad #2
Publisher:	Del Rey
Copyright:	November 1982
Printing:	March 1992
ISBN:	0-345-33565-1
Format:	Mass market
Pages:	322

Queen of Sorcery is the second book in the Belgariad, which is a "one story in five books" sort of series. You could probably take a chance on skipping Pawn of Prophecy, since it's not a very good book, but some parts of the story may be confusing without it. We're now getting into the part of the series where I can start saying some nice things about it, so I should put that in context and not get expectations too high. The Belgariad as a series is fully invested in the stock symbols and stereotypes of Tolkien-derivative fantasy. White is good; black is bad. West is good; east is bad. People are very neatly divided into countries, and national traits are exceptionally strong. The Murgos, the people who serve (although "under the thumb of" would be more accurate, Eddings doesn't spend much time thinking about the difference) the Big Bad of the series, are basically orcs, for all that they're theoretically human. With an unsympathetic reading, it's very easy to see the echos of the Yellow Peril in the war between the west and the east, including the standard trope of fractious, arguing, and diverse western kingdoms against a unified horde from the east. (To be fair, Eddings does undermine the unity a bit with the Nadraks later in the series, and my recollection is that the Mallorean, a follow-on series, undermines it even further.) Given that, I've been trying to figure out why I had fond memories of this series and enjoyed this re-read, since that normally isn't my thing. There are a few elements that are best talked about in the context of the next book, but one element shows up here as the party of heroes, finishing their forced detour in Cherek, head south through Arendia. Eddings is aware that he's stereotyping each nation of people in this world and embraces it so thoroughly that it stops feeling like stereotypes and starts feeling more like a fable. The Arends are a great example. Arendia is pure medieval fantasy world (even more so than the rest of this world). There are knights in castles, large forests reserved for noble hunting, and miserable serfs. The Arends, apart from the serfs, are full of tales of glory and honor, are impulsive and loyal to a fault, and are in the midst of a simmering internal war that's just barely not broken into open fighting. But the Arends know that they have an unhealthy obsession with honor, know that they constantly get themselves into trouble by being absolutist about honor and far too impulsive, and can't seem to help themselves. They bemoan the war while being apparently unable to do anything that would bring it to an end. If you think of them as people, none of this makes much sense. If you think of them as talking animals in a fable, aware of their natures but still governed by them, it starts to strangely work. When they're isolated from their society by joining the protagonists' party (the early part of this series mostly involves collecting people, for reasons explained later in the series, while following the trail of a thief), the characters of Eddings's world start developing a bit more nuance and depth. But even then, it's more within the bounds that one would expect in a long fable, and falls a bit short of human growth. The lion might learn something from the badger, but the lion is still a lion. With that frame, the first half of this book is rather entertaining. Eddings is taking the stereotype of the noble knight from a typical Arthurian romance and treating it like a class of animal in a fable, which I think is subtly delightful. There's even a doomed love triangle (a very chaste one, which is a reminder that this series was probably targeted at YA readers). The reader joins the primary characters in a sense of bemused exasperation. (Well, Garion takes the doomed love triangle much too seriously, but he's young). Unfortunately, the second half of this book is not one of the finest moments in this series. It's mostly a duet of whining. The first half of the whining comes from Garion, who finally discovers one of the many things about himself that's been obvious to the readers since the middle of the first book, and then promptly develops one of the worst cases of pathetic angst you'll encounter. The people who have been lying to him and keeping secrets from him are now all eager to teach him, which grates almost as much, whereas he's determined to never use his abilities. It makes me think the worst of absolutely everyone involved, and it all happens in one of the most depressing and disgusting settings of the book. The second half of the whining comes from Ce'Nedra, who is by far my least favorite character of this series. She's intended to be an obnoxious, spoiled, imperious brat, and also runs headlong into gender roles in this series, which means she's a living mass of irritation and gender stereotypes, made worse by the fact that the protagonists mostly tolerate her and Garion's reactions to her nonsense are also whiny and obnoxious. It's not my favorite bit of reading. Ce'Nedra does get marginally better later in the series, but she's at her worst here, at the same time Garion is at his worst, which makes the last half of this book a real chore. The only real plus side is that the voice in the back of Garion's head gets a few great moments, but more on that in the next book where it starts playing a prominent role. I should note here that Eddings isn't a complete disaster on gender in this series. There are a lot of unexamined stereotypes, but there are also a lot of examined ones, and it's obvious in places that he's trying. Polgara is a major character, women get some agency in this story, and they at least appear (which is never a given in Tolkien-derivative fantasy). But it's pretty obvious that gender roles start from a "men are from Mars, women are from Venus" set of expectations and then run into Eddings's general tendency to exaggerate all such divisions to fable levels, which in places isn't pretty. And, well, there are all-female giggly dryads who have to capture men to reproduce and who have a euphoric reaction to chocolate. That's a thing that happens. So you may or may not want to agree with me about the completeness of the disaster. Adjust expectations accordingly. If Queen of Sorcery had stuck with the tone of the first half of the book, I would say that it was doing something oddly interesting and showing some of the charm that made me want to re-read this series. Unfortunately, the second half of the book is a bit of a disaster, full of characters acting in ways that makes them very hard to like. Still, I plowed through this book in a couple nights of reading, so there's something here that draws one through the story. And the next book of the series is considerably better. Followed by Magician's Gambit. Rating: 6 out of 10

I got tired of manually fetching installation images via either FTP or by manually transferring files to z/VM to test s390x installs. Hence it was about time to automate it. Originally I wanted to instrument an installation via vmcp from another instance on the same host but I figured that I cannot really rely on a secondary instance when I need it and went the s3270/x3270-script way instead.

The resulting script isn't something I'm particularly proud of, especially as it misses error handling that really should be there. But this is not expect instead you operate on whole screens of data and z/VM is not particularly helpful in telling you that you just completed your logon either. Anyway, it seems to work for me. It downloads the most recent stable or daily image if they are not present yet, uploads them via DFT to CMS and makes sure that the installation does not terminate when the script disconnects. Sadly DFT is pretty slow, so I'm stuck with 70 kB/s and about five minutes of waiting until kernel and initrd are finally uploaded. Given that installations themselves are usually blazingly fast on System z, I'm not too annoyed by that, though.

I previously wrote about a parmfile example that sets enough options to bring debian-installer to the point of a working network console via SSH without further prompting. It's a little unfortunate that s390-netdevice needs to be preseeded with the hardware addresses of the network card in all cases, even if only one is available. I should go and fix that. For now this means that the parmfile will be dependent on the actual VM system definition. With that in mind there is an example script in the same gist that writes out a parmfile and then calls the reinstall script mentioned above. Given that debian-installer now supports HTTPS (so far only in the daily images) you can even do a reasonably secure bootstrapping of the network console credentials and preseeding settings.

If you put this pretty generic preseed configuration file onto a securely accessible webserver and reference it from the parmfile, you can also skip the more tedious questions at the beginning of debian-installer. A secure transport is encouraged as preseed files can do anything to your installation process. Unfortunately it seems that there is no way to preseed SSH keys for the resulting installation yet, neither for the created user nor for root. So I haven't achieved my desired target of a fully automated installation just yet. Debian's Jenkins setup just went with insecure defaults, but given that my sponsored VMs are necessarily connected to the public Internet that seemed like a bad idea to me. I suppose one way out would be to IP/password ACL the preseed file. Another one to somehow get SSH key support into user-setup.

A friend of mine choose for $reasons to install the latest OpenSuSE 42.2 release as his new laptop operating system. It's been a while that I had contact with the SuSE Linux distribution. Must be around 12 years or so. The unsual part here is that I've to support a somewhat eccentric, but mostly ordinary user of computers. And to my surprise it's still hard to just plug in your existing stuff and expect it work. I've done so many dirty things to this installation in the last three days, my system egineering heart is bleeding. printing with a Canon Pixma iP100 printer This is a small portable Canon printer, about four years old. It provides a decent quality and its main strength is that it's small and really portable. Sadly the gutenprint driver just pushes through a blank page. No ink wasted on it at all. So the only reasonable other choice was a four year old binary rpm package provided by Canon. It has a file dependency on "libtiff.so.3" which is no longer available in recent GNU/Linux distributions. So I cheated and

- unpacked the tarball
- installed the rpm from the "packages" folder
zypper install cnijfilter-common-3.70-1.x86_64.rpm cnijfilter-ip100series-3.70-1.x86_64.rpm
... and choose to ignore the missing file dependency on libtiff.so.5.
ln -s /usr/lib64/libtiff.so /usr/lib64/libtiff.so.5
- re-ran the ./install.sh which registered the printer with cups and does whatever else
  magic is included in 1906 lines of shell.

To my surprise this driver still works and provides the expected quality. Though it's just a question of time until this setup will break. Be it an incompatible ABI change in libtiff or another lib in use by those Canon provided tools. QGIS and gdal with ECW support While the printer stuff is a rather common use case, having a map viewer for map files in the ECW format is the eccentric part. I found some hints on stackoverflow and subsequently https://trac.osgeo.org/gdal/wiki/ECW that a non-free library is required and a specific build of gdal. Then QGIS should be able to work with ECW files. Lucky us there is at least a OpenSuSE repository for gdal and QGIS. So I did the following:

zypper addrepo http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.2/Application:Geo.repo
zypper install qgis

Then I had to download the non-free ECW SDK from http://download.hexagongeospatial.com/downloads/erdas-ecw-jp2-sdk-v5.3-%28linux%29 - you'll and up with a '.bin' installer file. The installation process left me with "ERDAS-ECW_JPEG_2000_SDK-5.3.0" folder in my $HOME. I moved that one to /opt. Next step is adding the library to the ldconfig search path.

echo "/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only/lib/x64/release/" > /etc/ld.so.conf.d/ecw.conf; ldconfig

Now it was "just" about rebuild gdal with ECW support. So I downloaded the required source packages with "zypper source-install gdal", edited the spec somewhere in "/usr/src/" to make the following modifications

--with-ecw=/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only

added to the "./configure" invocation. And somewhere at the top we had to relax the requirement that all installed files have to be referenced inside the package.

%define _unpackaged_files_terminate_build 0

As a last step I had to "rpmbuild -ba" the package and force the installation via zypper once more, because this time we have a file depedency on the libecw stuff and it's obviously not listed in the rpm database. Last but not least I tried to put the gdal build on hold with

zypper addlock gdal libgdal20

to ensure it's not removed on the next update. Other non-free tools Beside of those two issues I had to install a range of other non-free tools, but currently they work without further issues or modifications. One is Teamviewer (i686 multiarch rpm) and the other one is XnViewMP. XnView is also able to show ECW files, but only the smaller ones. It crashes on bigger ones but that's also the case on Windows. Then there is also (required by some Italian map related websites) the ugly Adobe Flash Plugin for Firefox, but that one is sadly still a widespread issue. We also tried to try out the nvidia graphic drivers but at the moment we could only get the build in Intel card to work. Usually the preferred solution from my point of view but sometimes we see rendering glitches and I'm not sure if it's the driver or something else. my personal take away I hate to admit it but it's nothing extraordinary that was requested here. But still it took me the better part of two evenings to figure everything out. And even now it's not properly integrated and doomed to fail any day due to various updates and changes in the surounding ecosystem. I've full sympathy for every average user that would give up after two hours of research and try&error on this journey. For the printer drivers I'm happy to blame Canon. The printer situation as a whole improved from my point of view during the last decade, but it's still a pain in the ass with the very short shelf life you usually see with consumer models. For the ECW case one could discuss if it would be legally possible and helpful to do ugly dlopen() stuff to dynamcially load the shared libs. But then again someone has to make his hands dirty during the build and discussions about the legal use of header files will be the next chapter (hello Oracle). It's just ugly. Actually I know too little about the world of image formats to judge if someone has a good reason to keep this format commercial or not. From my personal point of view it's not useful and maybe even morally wrong. Technically one could argue if it would make sense to keep a local copy of the gdal build in "/opt" and start QGIS with a modified library path to prefer the private gdal build. Not sure if that is any better. On the other hand there are evolving mechanism like flatpack that would ease the handling of such situations. Buth then again we would be catering non-free software. It feels a lot like giving up. While my private working environment is except for firmware blobs free, I now created for someone a real "FrankenSuSE" to satisfy his everyday needs. On the one hand we now have another mostly satisfied user of a mostly free operating system. On the other hand that was only possible by adding a vast amount of non-free software. For sure we did not win the war, I'm not even sure if we've won a single battle here. It's just frustrating to see what is required to get someone up and running. With my personal attitude towards open source software it even feels wrong to invest so much time into fiddling with non-free components. What is still missing We currently lack an image viewer that allows us to print only a selection of an image, which is useful to print parts of a map. That usually works with XnView on Windows but does not work with the Linux version at the moment. I also tried gwenview and geeqie and had the same issue. Not sure if it's maybe a bug in XnView or one of the Qt parts (gwenview is also Qt based). I did not research that yet. Update: I spent quite some time looking into open bug reports for geeqie and gwenview. Seems the feature to print only a section of an image is something new. I've created #374299 (gwenview) and #457 (geeqie). For XnView I expect it's a difference between XnViewMP (the portable version) and the Windows only XnView Classic. Needs to be clarified and it might be worth to try XnView Classic with wine. Maybe printing with wine via cups works, I found at least some results for it on the internet.

What happened in the Reproducible Builds effort between Sunday December 18 and Saturday December 24 2016: Media coverage 100% Of The 289 Coreboot Images Are Now Built Reproducibly by Phoronix, with more details in German by Pro-Linux.de. We have further reports on our Reproducible Builds World summit #2 in Berlin from Rok Garbas of NixOS as well as Clemens Lang of MacPorts Debian infrastructure work Dak now archives buildinfo files thanks to a patch from Chris Lamb. We also have mostly finalised a design of how they will be distributed by the Debian FTP mirror network which we will start implementing soon. This is great for the future of Debianb but unfortunately this also means that we won't have .buildinfo files for Stretch as Debian will not rebuild its source packages and because these binary packages currently in the archive were mostly built with dpkg > 1.18.11. reprepro/5.0.0-1 has added support for dealing with .buildinfo files that are included in .changes files. (Closes: #843402) Reproducible work in other projects The Chromium project is now working on making their build process (mostly) deterministic. Their motivation is to save both "[money] (less hardware is required) and developer time (reduced latency by having less work to do on the TS and CI)". Unreproducible bugs filed

• Chris Lamb:
  • #848721 filed against apt.
  • #848866 filed against libcorelinux.
  • #849314 filed against node-gulp.
  • #849333 filed against faker.
• Dhole:
  • #848633 filed against sugar-toolkit-gtk3.

Reviews of unreproducible packages 39 package reviews have been added, 75 have been updated and 44 have been removed in this week, adding to our knowledge about identified issues. 2 issue types have been updated:

• Updated captures_build_path
• Added nondeterministic_ordering_in_desktop_files_by_python_sugar3

Weekly QA work During our reproducibility testing, some FTBFS bugs have been detected and reported by:

• Adrian Bunk (1)
• Chris Lamb (7)
• Lucas Nussbaum (4)

diffoscope development diffoscope 66 was uploaded to unstable by Chris Lamb. It included contributions from:

• Emanuel Bronshtein:
  • Use ssh-keygen for comparing OpenSSH public keys
  • Use js-beautify as JavaScript code beautifier for .js files (with tests).
  • Many CSS & HTML improvements.
  • Change all HTTP URLs to HTTPS where applicable.
• anthraxx:
  • Enable the use of ssh-keygen on Arch Linux.
• Maria Glukhova:
  • Add detection of order-only difference in plain text format. (Closes: #848049)
  • Change icc-recognizing regexp to reflect changes in file type description. (Closes: #848814)
• Chris Lamb:
  • Update tests for compatibility with enjarify >= 1.0.3. (Closes: #849142)
  • When skipping tests because the version of an external is too low, print the detected version.
  • Avoid unpacking packages twice when comparing .changes. (Closes: #843531)
  • Add a simple profiling framework (enabled via --profile).
  • Various code quality and reliability improvements.
  • Document how to sign PyPI uploads.

strip-nondeterminism development strip-nondeterminism 0.029-1 was uploaded to unstable by Chris Lamb. It included no new content from this week, but rather included contributions from previous weeks. reproducible-website development The website is now also accessible via the https://www.reproducible-builds.org URL.

• Clemens Lang:
  • Add the definition of "reproducible", as drafted at the reproducible builds world summit in Berlin. Thanks to all participants in the sessions that worked these out!
• Valerie R Young:
  • Force ordering of titles.
  • Various formatting improvements.
• Holger Levsen:
  • Various usability and formatting improvements.
  • https://www.reproducible-builds.org
• Chris Lamb:
  • Various usability, style and wording improvements.
  • Add Debconf15, Skroutz.gz and MiniDebconfCambridge15 talks to resouces page.

tests.reproducible-builds.org

• We changed the data storage backend from a single sqlite3 database file (651 MB) to a PostgreSQL database. With this change we'll be able to scale a lot more and add testing of the arm64 architecture.
  • Valerie Young wrote most of the code, Mattia Rizzolo reviewed and helped improve the code and Holger deployed it and found some minor bugs which have been fixed.
• We are now testing the arm64 architecture for all packages on all suites, arranged by Holger. Many thanks to codethink for providing us with access to eight 8-core arm64 machines with 64GB memory, which allows us to rebuild Debian very fast!

Misc. This week's edition was written by Ximin Luo, Holger Levsen & Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC and the mailing lists.

The year 2016, which is about to end, has been full of work and contributions to the FLOSS comunity. Most of my focus goes to two important projects: Debian and Netfilter. This is no coincidence, since my main interests in the IT world are systems and networks. Some numbers (no exhaustive count):

• Netfilter patches/commits: ~60 contributions
• Netfilter docs/wiki: ~20 contributions
• Debian patches/commits: ~200 contributions
• Debian package uploads: ~30 uploads (also some sponsored uploads)
• Debian package maintenance: ~10 packages
• Number of non-technical people migrated to linux: 2!!

I would like to note that most of my work is done in my spare time, and nobody is paying for it (with the exeption of the Suricata debian package). My expectation for 2017 is to continue in this line, learn more and increment the quality of my contributions. I m especially proud of the the non-technical people who migrated to desktop linux due to my help. I m targeting 2 or 3 more friends and relatives for 2017. So, goodbye 2016! Exciting 2017 ahead.

Review: Pawn of Prophecy, by David Eddings

Series:	The Belgariad #1
Publisher:	Del Rey
Copyright:	April 1982
Printing:	August 1990
ISBN:	0-345-33551-1
Format:	Mass market
Pages:	258

I hit a period in November when I felt like reading something entirely undemanding and fun, something that was predictable, comfortable, and guaranteed to be a happy ending. There are times in life for books like that. I've been vaguely thinking of re-reading the Belgariad for a while, which I'd not read since I was in college, and that seemed to fit the bill. Garion is a farm-boy in Sendaria, a quiet and industrious kingdom full of farmers. His only family is his Aunt Pol, who ran the kitchen at Faldor's farm. His life has all the hallmarks of being entirely unremarkable, despite occasional visits by a traveling vagabond, Wolf, who clearly knows his Aunt Pol. But then something extremely important is stolen elsewhere, Wolf and Pol have to leave to pursue it for reasons that are quite murky to Garion, and Pol is unwilling to leave Garion behind. This begins Garion's great adventure, in which he becomes far more important and powerful than he would have ever imagined. That's the promise, at least, and the stock plot of every series like this. And let me be clear up front: the Belgariad is very stock. That's part of what I was in the mood for, but don't come to this series looking for interesting differentiation. It's clearly in the center of the secondary world chosen one fantasy genre, with a great evil, forces of good arrayed against it, and someone who unknowingly has the power to stop evil but has to learn how to use it. If you're in the mood for this, every note will be comfortably familiar; if not, it might be boringly predictable. Unfortunately, this particular book does not cast the Belgariad in a good light. Garion's introduction to this story is intensely irritating, almost entirely because no one will tell him what's going on. Pol is excessively protective (smotheringly so), but shuts down any questions he has and doesn't explain why she's freaking out. (This doesn't become entirely clear until towards the end of the second book.) What little scraps Garion picks up, he has to get by eavesdropping. Even by the end of this book, when Garion has met royalty and started helping with larger political issues (albeit mostly by accident), everyone is keeping him in the dark and he doesn't believe the hints he's gotten. I can't remember how I reacted to this the first time I read this series, but the second time through, it was extremely frustrating. The frustration is stronger because any regular reader of this genre knows exactly what Garion is, although not precisely how the story will play out, and can make fairly good guesses about Pol and Wolf from early in the story. Everyone playing coy doesn't even add legitimate suspense or set up a big reveal. It just made me irritated at Garion's blindness (it's mildly understandable given how foreign the idea is to his life, but he seems remarkably dense even with that), and even more irritated at Wolf and, in particular, Aunt Pol for keeping him so thoroughly in the dark. Garion is very attached to his aunt; on this re-reading, I wasn't entirely sure why. She occasionally shows love and support, and she's certainly wise, but for most of the book she treats him with brusque condescension and tries to keep him as ignorant as possible. Garion's weird entanglement with a black rider that he'd seen for most of his life doesn't make this any better. It's creepy and disturbing, it's not entirely resolved in this book, and Garion is clearly in danger, which wasn't the vibe that I was looking for when starting this re-read. And it's hard to escape the feeling that Garion might have managed to tell someone if all the adult figures in his life weren't so secretive, dismissive, and excessively controlling. So, all in all, an inauspicious beginning. It was good enough to keep me reading when I first read the series, and it was good enough on this re-read, but just barely. The saving grace is Silk and Barak, when the story finally meets them. Those who have read this series will know that they're just the beginning of the party-building process that will take up much of this series (so many Lord of the Rings resonances), but the one thing I will give Eddings is that he writes entertaining supporting characters. Both of them are a bit stereotyped, but they add so much to this story. Silk in particular is a delight and remains a delight throughout the series, adding a much-needed level of snark and sneaky enjoyment that lightens so many of the serious episodes of this story. The Belgariad in general is highly derivative map exploration fantasy, and you shouldn't expect anything deeper. It is, however, enjoyable map exploration fantasy with some entertaining supporting cast members. Sadly, only the glimmers of that are visible from this book. Pawn of Prophecy is mostly an irritating tour of bad parenting techniques, refusal to talk to teenagers, sneaking around to get information that should have been legitimately shared, and taking forever to get around to the mythology that we all know is coming. I therefore can't recommend this book, although one does have to read it in order to read the rest of the series, which as I recall gets considerably better. Followed by Queen of Sorcery. Rating: 5 out of 10

You may have noticed (but you probably did not), but on 2017-02-04, at 14:00, in room UB2.252A (aka "Lameere"), which at that point in time will be the Virtualisation and IaaS devroom, I'll be giving a talk on the Network Block Device protocol. Having been involved in maintaining NBD in one way or another for over fifteen years now, I've never seen as much activity around the concept as I have in the past few years. The result of that has been that we've added a number of new features to the protocol, to allow it to be used in settings where it was not as useful or as attractive as it would have been before. As a result, these are exciting times for those who care about NBD, and I thought it would be about time that I'd speak about it somewhere. The Virtualisation/IaaS devroom seemed like the right fit today (even though I wouldn't have thought so a mere two years ago), and so I'm happy they agreed to have me. While I still have to start writing my slides, and therefore don't really know (yet) exactly what I'll be talking about, the schedule already contains an outline. See you there?

Hello Dist::Zilla is a great tool to limit tedious tasks while working on Perl modules. For instance, dzil provides tools like dzil authordeps or dzil listdeps to list dependencies.
This list of Perl modules can then be installed with cpanm:

dzil authordeps --missing   cpanm
dzil listdeps --missing   cpanm

On a Debian system, one may prefer to install Perl modules using Debian packages. Installing build dependencies can be done with apt build-dep, but apt does not handle Dist::Zilla author dependencies. The new authordebs Dist::Zilla sub-command was wriiten to fill this gap. When run in a directory containing the source of a Perl module that uses Dist::Zilla, you can run dzil installdebs to list the Debian packages required to run the dzil command. You can also run dzil installdebs -install to install author dependencies (using sudo under the hood). See:

• authordebs doc
• An example of installation instructions using authordebs

On Debian, authordebs is provided by libdist-zilla-app-command-authordebs-perl All the best
Tagged: debian, dist-zilla, Perl

While learning about and configuring weechat this evening, I noticed a lot of complexity and unsatisfying tradeoffs related to its UI, its mouse support, and its built-in window system. Got to wondering what I'd do differently, if I wrote my own IRC client, to avoid those problems. The first thing I realized is, it is not a good idea to think about writing your own IRC client. Danger will robinson.. So, let's generalize. This blog post is not about designing an IRC client, but about exploring simpler ways that something like an IRC client might handle its UI, and perhaps designing something general-purpose that could be used by someone else to build an IRC client, or be mashed up with an existing IRC client. What any modern IRC client needs to do is display various channels to the user. Maybe more than one channel should be visible at a time in some kind of window, but often the user will have lots of available channel and only want to see a few of them at a time. So there needs to be an interface for picking which channel(s) to display, and if multiple windows are shown, for arranging the windows. Often that interface also indicates when there is activity on a channel. The most recent messages from the channel are displayed. There should be a way to scroll back to see messages that have already scrolled by. There needs to be an interface for sending a message to a channel. Finally, a list of users in the channel is often desired. Modern IRC clients implement their own UI for channel display, windowing, channel selection, activity notification, scrollback, message entry, and user list. Even the IRC clients that run in a terminal include all of that. But how much of that do they need to implement, really? Suppose the user has a tabbed window manager, that can display virtual terminals. The terminals can set their title, and can indicate when there is activity in the terminal. Then an IRC client could just open a bunch of terminals, one per channel. Let the window manager handle channel selection, windowing (naturally), and activity notification. For scrollback, the IRC client can use the terminal's own scrollback buffer, so the terminal's regular scrollback interface can be used. This is slightly tricky; can't use the terminal's alternate display, and have to handle the UI for the message entry line at the bottom. That's all the UI an IRC client needs (except for the user list), and most of that is already implemented in the window manager and virtual terminal. So that's an elegant way to make an IRC client without building much new UI at all. But, unfortunately, most of us don't use tabbed window managers (or tabbed terminals). Such an IRC client, in a non-tabbed window manager, would be a many-windowed mess. Even in a tabbed window manager, it might be annoying to have so many windows for one program. So we need fewer windows. Let's have one channel list window, and one channel display window. There could also be a user list window. And there could be a way to open additional, dedicated display windows for channels, but that's optional. All of these windows can be seperate virtual terminals. A potential problem: When changing the displayed channel, it needs to output a significant number of messages for that channel, so that the scrollback buffer gets populated. With a large number of lines, that can be too slow to feel snappy. In some tests, scrolling 10 thousand lines was noticiably slow, but scrolling 1 thousand lines happens fast enough not to be noticiable. (Terminals should really be faster at scrolling than this, but they're still writing scrollback to unlinked temp files.. sigh!) An IRC client that uses multiple cooperating virtual terminals, needs a way to start up a new virtual terminal displaying the current channel. It could run something like this:

x-terminal-emulator -e the-irc-client --display-current-channel

That would communicate with the main process via a unix socket to find out what to display. Or, more generally:

x-terminal-emulator -e connect-pty /dev/pts/9

connect-pty would simply connect a pty device to the terminal, relaying IO between them. The calling program would allocate the pty and do IO to it. This may be too general to be optimal though. For one thing, I think that most curses libraries have a singleton terminal baked into them, so it might be hard to have a single process control cursors on multiple pty's. And, it might be innefficient to feed that 1 thousand lines of scrollback through the pty and copy it to the terminal. Less general than that, but still general enough to not involve writing an IRC client, would be a library that handled the irc-client-like channel display, with messages scrolling up the terminal (and into the scrollback buffer), a input area at the bottom, and perhaps a few other fixed regions for status bars and etc. Oh, I already implemented that! In concurrent-output, over a year ago: a tiling region manager for the console I wonder what other terminal applications could be simplified/improved by using multiple terminals? One that comes to mind is mutt, which has a folder list, a folder view, and an email view, that all are shoehorned, with some complexity, into a single terminal.

I am sad (but feel my duty) to inform the world that we will not be providing a Drupal 8 package in Debian. I filed an Intent To Package bug a very long time ago, intending to ship it with Jessie; Drupal 8 was so deep a change that it took their community overly long to achieve and stabilize. Still, Drupal 8 was released over a year ago today. I started working on debianizing the package shortly afterwards. There is also some online evidence As my call for help sent through this same blog. I have been too busy this last year. I let the packaging process lay dormant for too long, without even touching it for even half a year. Then, around September, I started working with the very nice guys of Indava, David and Enrique, and did very good advances. They clearly understood Debian's needs when it comes to full source inclusion (as D8 ships many minified Javascript libraries), attribution (as additionally to all those, many third-party PHP projects are bundled in the infamous vendor/ directory), and system-wide dependency management (as Drupal builds on some frameworks and libraries already available within Debian, chiefly Symfony, Doctrine, Twig... Even more, most of them appeared to work at the version levels we will be shipping, so all was dandy and for some weeks, I was quite optimistic on finishing the package on time and with the needed quality and testing. Yay! But... Reality bites. When I started testing my precious package... It broke in horrible ways. Uncomprehensible PHP errors (and I have to add here, I am a PHP newbie and am reluctant to learn better a language that strikes me as so inconsistent, so ugly), which we spent some time tackling... Of course, configuration changes are more than expected... But, just as we Debianers learnt some important lessons after the way-too-long Sarge freeze (ten years ago, many among you won't remember those frustrating days), Drupal learnt as well. They changed their release strategy Instead of describing it, those interested can read it at its source. What it meant for me, sadly, is that this process does not align with the Debian maintenance model. This means: The Drupal API stays mostly-stable between 8.0.x, 8.1.x, 8.2.x, etc. However, Drupal will incorporate new versions of their bundled libraries. I understood the new versions would be incorporated at minor-level branches, but if I read correctly some of my errors, some dependencies change even at patch-level updates. And... Well, if you update a PHP library, and the invoking PHP code (that is, Drupal) relies in this new version... Sadly, it makes it unmaintainable for Debian. So, long story short: I have decided to drop Drupal8 support in Debian. Of course, if somebody wants to pick up the pieces, the Git repository is still there (although I do plan on erasing it in a couple of weeks, as it means useless waste of project resources otherwise), and you could probably even target unstable+backports in a weird way (as it's software that, given our constraints, shouldn't enter testing, at least during a freeze). So... Sigh, a tear is dropped for every lost hour of work, and my depeest regrets to David and Enrique who put their work as well to make D8 happen in Debian. I will soon be closing the ITP and... Forgetting about the whole issue?

Sorry about the duplicates showing up in your feed or in e-mail, for those who saw them. I changed the canonical URLs of my journal entries to use https instead of http and forgot that would confuse a lot of RSS readers. Didn't mean to suddenly give you all a replay of the last 15 entries! This should be a one-time change and not happen again. (Although I need to find or fix a good broken link checker and then track down the rest of the URLs in my web site that aren't using https.)

I used to rely on ifupdown to bring up my iptables firewall automatically using a config like this in /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
    pre-up /sbin/iptables-restore /etc/network/iptables.up.rules
    pre-up /sbin/ip6tables-restore /etc/network/ip6tables.up.rules
allow-hotplug wlan0
iface wlan0 inet dhcp
    pre-up /sbin/iptables-restore /etc/network/iptables.up.rules
    pre-up /sbin/ip6tables-restore /etc/network/ip6tables.up.rules

but that doesn't seem to work very well in the brave new NetworkManager world. What does work reliably is a "pre-up" NetworkManager script, something that gets run before a network interface is brought up. However, despite what the documentation says, a dispatcher script in /etc/NetworkManager/dispatched.d/ won't work on my Debian and Ubuntu machines. Instead, I had to create a new iptables script in /etc/NetworkManager/dispatcher.d/pre-up.d/:

#!/bin/sh
LOGFILE=/var/log/iptables.log
if [ "$1" = lo ]; then
    echo "$0: ignoring $1 for \ $2'" >> $LOGFILE
    exit 0
fi
case "$2" in
    pre-up)
        echo "$0: restoring iptables rules for $1" >> $LOGFILE
        /sbin/iptables-restore /etc/network/iptables.up.rules >> $LOGFILE 2>&1
        /sbin/ip6tables-restore /etc/network/ip6tables.up.rules >> $LOGFILE 2>&1
        ;;
    *)
        echo "$0: nothing to do with $1 for \ $2'" >> $LOGFILE
        ;;
esac
exit 0

and then make that script executable:

chmod a+x /etc/NetworkManager/dispatcher.d/pre-up.d/iptables

With this in place, I can put my iptables rules in the usual place (/etc/network/iptables.up.rules and /etc/network/ip6tables.up.rules) and use the handy iptables-apply and ip6tables-apply commands to test any changes to my firewall rules.

Review: The Kingdom of Gods, by N.K. Jemisin

Series:	Inheritance #3
Publisher:	Orbit
Copyright:	2011
Printing:	April 2012
ISBN:	0-316-04394-X
Format:	Mass market
Pages:	567

The Kingdom of Gods is the third and final book of the Inheritance trilogy and rests very heavily on the events of The Hundred Thousand Kingdoms and The Broken Kingdoms. I think it's the best book of the trilogy as well, but this isn't the place to start. The build-up from the previous books is very important to this story. The first book of this series followed Yeine in her introduction to the highly political, abusive, and exploitative world of the Arameri, and her deeper introduction to the complex theology and mythology of Jemisin's constructed world. The second involved fewer theological fireworks and more day-to-day decisions, but it followed the implications of the first book's climax and revealed another important lurking weapon from the past. The Kingdom of Gods returns to a theological focus, this time putting Sieh front and center, and is once again concerned with the fate of the entire world, or even reality itself. Sieh played a significant role in the first book, but only seen from Yeine's perspective. He's the trickster god, the god of childhood, of play and whim and unfairness and practical jokes, of all the chaos and lack of impulse control and impudence of childhood. The Kingdom of Gods opens with him encountering two Arameri children in the abandoned areas under Sky and making an unlikely and impulsive pledge of friendship. One that leads to an unexplained catastrophe, a long blackout, and possibly the end of his existence, since Sieh starts aging. And growing up directly undermines his power. One of the two children turns out to be the heir of the haughty, devious, and deeply racist Arameri, whose position atop the hierarchy of the world has been weakened by earlier events but not shaken entirely. Her relationship with Sieh is much more fraught and complex when both of them are teenagers and Sieh is struggling badly to remain true to himself. But what drives the plot is a deadly new form of magic that is targeting the Arameri family and threatening to bring back world-wide war. This is my favorite book of the trilogy, not so much because it brings a relatively satisfying conclusion (The Hundred Thousand Kingdoms wasn't bad at that either), but because for once I like all of the main characters. Yeine and Nahadoth are hit and miss (the second two books of the trilogy make it clear that Nahadoth can be a real asshole), and as mentioned in the review of The Broken Kingdoms, I found Shiny exasperating. But Sieh is fun, even when he's being obnoxious, and both of the kids he befriends are complex and multifaceted. Shahar, with her hard and complex relationship with her mother, is probably my favorite character in the book, but her brother certainly has his moments. I did not like Sieh's maturation process. There are parts of this story that are squirm-inducing, and not in a good way (at least for me). And he does tend to get whiny in places. But he knows everyone in Jemisin's complex mythology, he has a great first-person narrative voice, and there are some very fun moments of interaction with his sibling gods. It says something that I really enjoyed this story even though books about slow, ongoing illness and diminution are rather far from my favorites (and Sieh's aging falls into that category). While there are some beautiful set-pieces here once the shit starts to hit the fan in earnest, the concluding fireworks didn't really work for me. The final confrontation was too abstracted, too indescribable, and too full of ancillary carnage to be the ending I was looking for. (Perhaps because of what I've been playing recently, I keep thinking of it as one of those chaotic, floating, dream-like cut-scene disasters in a Final Fantasy game that's trying to hint at indescribable magic.) But the denouement made me happy, and it fit the characters. And don't miss the glossary at the end of the book that Sieh has scribbled all over. This book includes, as a bonus, a short story: "Not the End": This is the ending that The Broken Kingdoms actually needed. It (plus some key bits in the rest of The Kingdom of Gods) made me feel much better about the end of that book, and added a much-needed light note to the rather heavy bits at the end of this book. And I do love Oree. It's very short, and it's not in any way a standalone story (more of a belated epilogue to the previous novel), but that's all that was needed. (8) Rating: 8 out of 10

There s a pattern that comes up from time to time in the release management of free software projects. To allow for big, disruptive changes, a new development branch is created. Most of the developers focus moves to the development branch. However at the same time, the users focus stays on the stable branch. As a result:

• The development branch lacks user testing, and tends to make slower progress towards stabilization.
• Since users continue to use the stable branch, it is tempting for developers to spend time backporting new features to the stable branch instead of improving the development branch to get it stable.

This situation can grow up to a quasi-deadlock, with people questioning whether it was a good idea to do such a massive fork in the first place, and if it is a good idea to even spend time switching to the new branch. To make things more unclear, the development branch is often declared stable by its developers, before most of the libraries or applications have been ported to it. This has happened at least three times. First, in the Linux 2.4 / 2.5 era. Wikipedia describes the situation like this:

Before the 2.6 series, there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. Both of these branches had been maintained by the same set of people, led by Torvalds. This meant that users would always have a well-tested 2.4 version with the latest security and bug fixes to use, though they would have to wait for the features which went into the 2.5 branch. The downside of this was that the stable kernel ended up so far behind that it no longer supported recent hardware and lacked needed features. In the late 2.5 kernel series, some maintainers elected to try backporting of their changes to the stable kernel series, which resulted in bugs being introduced into the 2.4 kernel series. The 2.5 branch was then eventually declared stable and renamed to 2.6. But instead of opening an unstable 2.7 branch, the kernel developers decided to continue putting major changes into the 2.6 branch, which would then be released at a pace faster than 2.4.x but slower than 2.5.x. This had the desirable effect of making new features more quickly available and getting more testing of the new code, which was added in smaller batches and easier to test. Then, in the Ruby community. In 2007, Ruby 1.8.6 was the stable version of Ruby. Ruby 1.9.0 was released on 2007-12-26, without being declared stable, as a snapshot from Ruby s trunk branch, and most of the development s attention moved to 1.9.x. On 2009-01-31, Ruby 1.9.1 was the first release of the 1.9 branch to be declared stable. But at the same time, the disruptive changes introduced in Ruby 1.9 made users stay with Ruby 1.8, as many libraries (gems) remained incompatible with Ruby 1.9.x. Debian provided packages for both branches of Ruby in Squeeze (2011) but only changed the default to 1.9 in 2012 (in a stable release with Wheezy 2013). Finally, in the Python community. Similarly to what happened with Ruby 1.9, Python 3.0 was released in December 2008. Releases from the 3.x branch have been shipped in Debian Squeeze (3.1), Wheezy (3.2), Jessie (3.4). But the python command still points to 2.7 (I don t think that there are plans to make it point to 3.x, making python 3.x essentially a different language), and there are talks about really getting rid of Python 2.7 in Buster (Stretch+1, Jessie+2). In retrospect, and looking at what those projects have been doing in recent years, it is probably a better idea to break early, break often, and fix a constant stream of breakages, on a regular basis, even if that means temporarily exposing breakage to users, and spending more time seeking strategies to limit the damage caused by introducing breakage. What also changed since the time those branches were introduced is the increased popularity of automated testing and continuous integration, which makes it easier to measure breakage caused by disruptive changes. Distributions are in a good position to help here, by being able to provide early feedback to upstream projects about potentially disruptive changes. And distributions also have good motivations to help here, because it is usually not a great solution to ship two incompatible branches of the same project. (I wonder if there are other occurrences of the same pattern?) Update: There s a discussion about this post on HN

I recently needed to get access to a DataEase database; the person I helped was the legitimate owner of the data, but had forgotten the password, as the database was largely from 1996. There are various companies around the world that seem to do this, or something similar (like give you an API), for a usually unspecified fee; they all have very 90s homepages and in general seem like they have gone out of business a long time ago. And I wasn't prepared to wait. For those of you who don't know DataEase, it's a sort-of relational database for DOS that had its heyday in the late 80s and early 90s (being sort of the cheap cousin of dBase); this is before SQL gained traction as the standard query language, before real multiuser database access, and before variable-width field storage. It is also before reasonable encryption. Let's see what we can do. DataEase has a system where tables are mapped through the data dictionary, which is a table on its own. (Sidenote: MySQL pre-8.0 still does not have this.) This is the file RDRRTAAA.DBM; I don't really know what RDRR stands for, but T is the database letter in case you wanted more than one database in the same directory, and AAA, AAB, AAC etc. is a counter so that a table grows to be too big for one file. (There's also .DBA files for structure of non-system tables, and then some extra stuff for indexes.) DBM files are pretty much the classical, fixed-length 80s-style database files; each row has some flags (I believe these are for e.g. row is deleted ) and then just the rows in fixed format right after each other. For instance, here's one I created as part of testing (just the first few lines of the hexdump are shown):

00000000: 0e 00 01 74 65 73 74 62 61 73 65 00 00 00 00 00  ...testbase.....
00000010: 00 00 00 00 00 00 00 73 46 cc 29 37 00 09 00 00  .......sF.)7....
00000020: 00 00 00 00 00 43 3a 52 44 52 52 54 41 41 41 2e  .....C:RDRRTAAA.
00000030: 44 42 4d 00 00 01 00 0e 00 52 45 50 4f 52 54 20  DBM......REPORT 
00000040: 44 49 52 45 43 54 4f 52 59 00 00 00 00 00 1c bd  DIRECTORY.......
00000050: d4 1a 27 00 00 00 00 00 00 00 00 00 43 3a 52 45  ..'.........C:RE
00000060: 50 4f 54 41 41 41 2e 44 42 4d 00 00 01 00 0e 00  POTAAA.DBM......
00000070: 52 65 6c 61 74 69 6f 6e 73 68 69 70 73 00 00 00  Relationships...

Even without going in-depth, we can see the structure here; there's testbase which maps to C:RDRRTAA.DBM (the RDRR itself), there's a table called REPORT DIRECTORY that maps to C:REPOTAAA.DBM, and then more stuff after that, and so on. However, other tables are not so easily read, because you can ask DataEase to encrypt a table. Let's look at such an encrypted table, like the Users table (containing usernames, passwords not password hashes and some extra information like access level), which is always encrypted:

00000000: 0c 01 9f ed 94 f7 ed 34 ba 88 9f 78 21 92 7b 34  .......4...x!. 4
00000010: ba 88 0f d9 94 05 1e 34 ba 88 a0 78 21 92 7b 34  .......4...x!. 4
00000020: e2 88 9f 78 21 92 7b 34 ba 88 9f 78 21 92 7b 34  ...x!. 4...x!. 4
00000030: ba 88 9f 78 21 92 7b 34 ba 88 9f 78 21 92 7b     ...x!. 4...x!. 

Clearly, this isn't very good encryption; it uses a very short, repetitive key of eight bytes (64 bits). (The data is mostly zero padding, which makes it much easier to spot this.) In fact, in actual data tables, only five of these bytes are set to a non-zero value, which means we have a 40-bit key; export controls? My first assumption here was of course XOR, but through some experimentation, it turned out what you need is actually 8-bit subtraction (with wraparound). The key used is derived from both a database key and a per-table key, both stored in the RDRR; again, if you disassemble, I'm sure you can find the key derivation function, but that's annoying, too. Note, by the way, that this precludes making an attack by just copying tables between databases, since the database key is different. So let's do a plaintext attack. If you assume the plaintext of the bottom row is all padding, that's your key and here's what you end up with:

00000000: 52 79 00 75 73 65 72 00 00 00 00 00 00 00 00 00  Ry.user.........
00000010: 00 00 70 61 73 73 a3 00 00 00 01 00 00 00 00 00  ..pass..........
00000020: 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  (...............
00000030: 00 00 00 00 00 00 00 00                          ........ 

Not bad, eh? Actually the first byte of the key here is wrong as far as I know, but it didn't interfere with the fields, so we have what we need to log in. (At that point, we've won, because DataEase will helpfully decrypt everything transparent for us.) However, there's a twist; if the password is longer than four characters, the entire decryption of the Users table changes. Of course, we could run our plaintext attack against every data table and pick out the information by decoding the structure, but again; annoying. So let's see what it looks like if we choose passs instead:

00000000: 0e 01 9f 7a ae 9e 21 f5 08 63 07 6d a3 a1 17 5d  ...z..!..c.m...]
00000010: 70 cb df 36 7e 7c 91 c5 d8 33 d8 3d 73 71 e7 2d  p..6~ ...3.=sq.-
00000020: 7b 9b 3f a5 db d9 4f 95 a8 03 a7 0d 43 41 b7 fd   .?...O.....CA..
00000030: 10 6b 0f 75 ab a9 1f 65 78 d3 77 dd 13 11 87     .k.u...ex.w....

Distinctly more confusing. At this point, of course, we know at which byte positions the username and password start, so if we wanted to, we could just try setting the start byte of the password to every possible byte in turn until we hit 0x00 (DataEase truncates fields at the first zero byte), which would allow us to get in with an empty password. However, I didn't know the username either, and trying two bytes would mean 65536 tries, and I wasn't up for automating macros through DOSBox. So an active attack wasn't too tempting. However, we can look at the last hex byte (where we know the plaintext is 0); it goes 0x5d, 0x2d, 0xfd... and some other bytes go 0x08, 0xd8, 0xa8, 0x78, and so on. So clearly there's an obfuscation here where we have a per-line offset that decreases with 0x30 per line. (Actually, the increase/decrease per line seems to be derived from the key somehow, too.) If we remove that, we end up with:

00000000: 0e 01 9f 7a ae 9e 21 f5 08 63 07 6d a3 a1 17 5d  ...z..!..c.m...]
00000010: a0 fb 0f 66 ae ac c1 f5 08 63 08 6d a3 a1 17 5d  ...f.....c.m...]
00000020: db fb 9f 05 3b 39 af f5 08 63 07 6d a3 a1 17 5d  ....;9...c.m...]
00000030: a0 fb 9f 05 3b 39 af f5 08 63 07 6d a3 a1 17     ....;9...c.m...

Well, OK, this wasn't much more complicated; our fixed key is now 16 bytes long instead of 8 bytes long, but apart from that, we can do exactly the same plaintext attack. (Also, it seems to change per-record now, but we don't see it here, since we've only added one user.) Again, assume the last line is supposed to be all 0x00 and thus use that as a key (plus the last byte from the previous line), and we get:

00000000: 6e 06 00 75 73 65 72 00 00 00 00 00 00 00 00 00  n..user.........
00000010: 00 00 70 61 73 73 12 00 00 00 01 00 00 00 00 00  ..pass..........
00000020: 3b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ;...............
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ...............

Well, OK, it wasn't perfect; we got pass\x12 instead of passs , so we messed up somehow. I don't know exactly why the fifth character gets messed up like this; actually, it cost me half an hour of trying because the password looked very real but the database wouldn't let me in, but eventually, we just guessed at what the missing letter was supposed to be. So there you have it; practical small-scale cryptanalysis of DOS-era homegrown encryption. Nothing advanced, but the user was happy about getting the data back after a few hours of work. :-)

krb5-strength provides password strength checking plugins and programs for MIT Kerberos and Heimdal, and a password history implementation for Heimdal. This is the first new upstream release since I left Stanford, since I don't personally use the package any more. But it's easy enough to maintain, and it was overdue for merging some contributed patches. This release adds a new configuration directive, cracklib_maxlen, which can be used to not run longer passwords through CrackLib (whose concepts of password strength were not designed for longer passwords and which can spuriously reject passphrases). It also allows require_classes to require a certain number of character classes in a password, not just specific classes. There are also a variety of portability and cleanup fixes. Thanks to Jorj Bauer, Toby Blake, and Bernt Jernberg for their contributions. I've merged into the embedded CrackLib all the relevant security patches that have come out, although none of them turned out to be relevant for this package due to how CrackLib was called. I also applied a patch from Mark Sirota to fix mkdict and packer to force C locale, which keeps them from creating corrupted dictionaries. Finally, configuration instructions for the plugin are now installed as a new krb5-strength man page, and configuration instructions are included in the heimdal-history and heimdal-strength man pages, instead of just being in the README file. This makes them more accessible after the package is installed. You can get the latest version from the krb5-strength distribution page.

krb5-strength provides password strength checking plugins and programs for MIT Kerberos and Heimdal, and a password history implementation for Heimdal. This is the first new upstream release since I left Stanford, since I don't personally use the package any more. But it's easy enough to maintain, and it was overdue for merging some contributed patches. This release adds a new configuration directive, cracklib_maxlen, which can be used to not run longer passwords through CrackLib (whose concepts of password strength were not designed for longer passwords and which can spuriously reject passphrases). It also allows require_classes to require a certain number of character classes in a password, not just specific classes. There are also a variety of portability and cleanup fixes. Thanks to Jorj Bauer, Toby Blake, and Bernt Jernberg for their contributions. I've merged into the embedded CrackLib all the relevant security patches that have come out, although none of them turned out to be relevant for this package due to how CrackLib was called. I also applied a patch from Mark Sirota to fix mkdict and packer to force C locale, which keeps them from creating corrupted dictionaries. Finally, configuration instructions for the plugin are now installed as a new krb5-strength man page, and configuration instructions are included in the heimdal-history and heimdal-strength man pages, instead of just being in the README file. This makes them more accessible after the package is installed. You can get the latest version from the krb5-strength distribution page.

it's amazing how many new bugs appear; luckily in the Debian Perl Group we're not too bad at fixing them as well. here's the list of my contributions over the last weeks:

• #828387 src:libcrypt-openssl-rsa-perl: "libcrypt-openssl-rsa-perl: FTBFS with openssl 1.1.0"
  add patch from Sebastian Andrzej Siewior (pkg-perl)
• #839322 src:libmoops-perl: "libmoops-perl: FTBFS: build-dependency not installable: libkavorka-perl"
  close, as dependency is fixed (pkg-perl)
• #840305 src:libatteanx-store-memorytriplestore-perl: "libatteanx-store-memorytriplestore-perl: depends on unavailable AtteanX::RDFQueryTranslator"
  investigate (pkg-perl)
• #842753 libnet-sip-perl: "FTBFS: test failures"
  import new upstream release (pkg-perl)
• #844141 src:libsys-cpuaffinity-perl: "libsys-cpuaffinity-perl: FTBFS: Failed test 'bind to all processors successful 18446744073709551615 == 18446744073709551616-1'"
  import new upstream release, later reopen & downgrade (pkg-perl)
• #844538 src:libdbd-mysql-perl: "libdbd-mysql-perl: FTBFS on some architectures"
  import new upstream release (pkg-perl)
• #844950 src:libdatetime-format-duration-perl: "libdatetime-format-duration-perl must build-depend on libparams-validate-perl"
  add missing (build) dependency, upload to DELAYED/5
• #846059 src:libmath-bigint-gmp-perl: "libmath-bigint-gmp-perl: FTBFS: Failed 1/12 test programs (t/bigintpm.t)"
  import new upstream release (pkg-perl)
• #846721 src:libaudio-mpd-perl: "libaudio-mpd-perl: FTBFS: Test failures"
  skip a brittle test (pkg-perl)
• #846731 src:libbio-scf-perl: "libbio-scf-perl: FTBFS: Test failures"
  add patch from ntyni (pkg-perl)
• #847176 libbusiness-ismn-perl: "libbusiness-ismn-perl: FTBFS: t/prereq.t failure"
  import new upstream release (pkg-perl)
• #847188 libtest-data-perl: "libtest-data-perl: FTBFS: t/prereq.t failure"
  import new upstream release (pkg-perl)
• #847189 libbusiness-issn-perl: "libbusiness-issn-perl: FTBFS: t/prereq.t failure"
  import new upstream release (pkg-perl)
• #847397 src:libimager-perl: "libimager-perl FTBFS on mips/mipsel: Failed 10/66 test programs"
  build with -O0 on mips/mipsel (pkg-perl)
• #848060 src:libx11-protocol-other-perl: "libx11-protocol-other-perl: FTBFS randomly (failing tests)"
  disable fragile test (pkg-perl)
• #848266 src:libparanoid-perl: "libparanoid-perl: FTBFS: tests timeout"
  skip a test (pkg-perl)
• #848346 libio-socket-ssl-perl: "libio-socket-ssl-perl: default certificate path lost with libssl1.1"
  import new upstream release (pkg-perl)
• #848427 libanyevent-perl: "libanyevent-perl: FTBFS with openssl 1.1: t/80_ssltest.t failure"
  apply upstream patch (pkg-perl)