Review: One Salt Sea, by Seanan McGuire

Series:	October Daye #5
Publisher:	DAW
Copyright:	September 2011
ISBN:	1-101-54760-X
Format:	Kindle
Pages:	368

This is the fifth book of the October Daye series. It's the best book of the series to date, at least in my opinion, but this is a series with a substantial cast and political complications. You could probably start here and work out things on the fly, since each story is largely self-contained, but much of the emotional resonance would be lost. As expected for this series, Toby's life doesn't have much time to stabilize after the events of Late Eclipses. This time, though, the initial threat is less personal and more political. The children of the rulers of the Duchy of Saltmist have been kidnapped, and war between Saltmist and the Kingdom of the Mists (Toby's home) is very near. All that stands in the way of horrible casualties, of fae that can scarce afford more death, is Toby's desperate detective work. Toby's confidence and belief in her own abilities has been growing steadily throughout this series. One of my favorite themes in fiction is someone who doesn't really believe in themselves but tries anyway, because they couldn't live with themselves if they didn't, and discovers they're more capable than they thought. In this series, I think that works best when Toby is less scared and more angry, which is very true in One Salt Sea. That's one reason why I liked this book better than either An Artificial Night or Late Eclipses. Another is that I love the politics and the depth of world-building and lore that McGuire brings to this series, and One Salt Sea is a showcase of both. We get the Undersea Duchy of Saltmist, which comes from both different traditions and different fae than the series so far. We get a plot that combines political maneuvering with a more traditional detective story than the last few books. We get more hidden traditions, past alliances and enmity that Toby didn't know about, and further development of Toby's own abilities. She has to tug hard on some threads, move between levels of the fae world, and draw on her network for uniquely fae forms of forensic analysis. I thoroughly enjoyed it, particularly the rocks. (You'll know what I mean when you get to that part.) But the best thing about this book, by far, is the Luidaeg. I've mentioned in reviews of previous books that the Luidaeg is my favorite character of the series. One Salt Sea just cements that. This is the deepest that the Luidaeg has been involved in a story: she gives Toby her mission at the start, substantial help along the way, and is deeply involved in the ending. We even learn some of her own background, and some of her own worries and pain. (And foreshadowing that there's more of this to come, which I'm eagerly looking forward to.) She's moved from a strange ally through a cautious friend to some combination of aunt and mother to Toby, while always staying her irascible and occasionally painful self. The bits with her in this book are the best so far, and there are a lot of them. It's a delightful reading experience. McGuire also uses this story to clear up a plot element that's been lingering since the first book of the series, but that never worked emotionally for me. (I'm talking about this indirectly since it's a significant spoiler.) It's a great resolution, one with heft and emotion and hard choices and pain, and largely makes up for the showing rather than telling that we've gotten in the previous books, while also (at least I suspect) graciously shuffling that plot out of the way in future books. It's a good bit of series work and personal growth for Toby, and I think frees the series to focus on the bits I enjoy the most. The ending of One Salt Sea hurts, but it's a good hurt, full of hard choices made well, bravery, and sacrifice. The best moments of this series have always had that, but I think this book is the most successful delivery of the whole package to date. This has always been a solid urban fantasy series, but I think it's getting better as it goes along. One major reason is that McGuire doesn't seem to be running out of world-building oomph. In a lot of urban fantasy, particularly the werewolf and vampire sort, I feel like the lore gets thinner, more rehashed, and more mundane as the series ages. But McGuire is still introducing new elements, showing existing elements from new directions and in new light, and has been slowly building major puzzles around Toby's life and abilities that intrigue me. And, even more rare, the eventual revelations usually live up to the preceding tension. It's certainly a recipe to keep me reading. Followed by Ashes of Honor. Rating: 9 out of 10

I gave a presentation at 32C3 this week. One of the things I said was "If any of you are doing seriously confidential work on Apple laptops, stop. For the love of god, please stop." I didn't really have time to go into the details of that at the time, but right now I'm sitting on a plane with a ridiculous sinus headache and the pseudoephedrine hasn't kicked in yet so here we go.

The basic premise of my presentation was that it's very difficult to determine whether your system is in a trustworthy state before you start typing your secrets (such as your disk decryption passphrase) into it. If it's easy for an attacker to modify your system such that it's not trustworthy at the point where you type in a password, it's easy for an attacker to obtain your password. So, if you actually care about your disk encryption being resistant to anybody who can get temporary physical possession of your laptop, you care about it being difficult for someone to compromise your early boot process without you noticing.

There's two approaches to this. The first is UEFI Secure Boot. If you cryptographically verify each component of the boot process, it's not possible for a user to compromise the boot process. The second is a measured boot. If you measure each component of the boot process into the TPM, and if you use these measurements to control access to a secret that allows the laptop to prove that it's trustworthy (such as Joanna Rutkowska's Anti Evil Maid or my variant on the theme), an attacker can compromise the boot process but you'll know that they've done so before you start typing.

So, how do current operating systems stack up here?

Windows: Supports UEFI Secure Boot in a meaningful way. Supports measured boot, but provides no mechanism for the system to attest that it hasn't been compromised. Good, but not perfect.

Linux: Supports UEFI Secure Boot[1], but doesn't verify signatures on the initrd[2]. This means that attacks such as Evil Abigail are still possible. Measured boot isn't in a good state, but it's possible to incorporate with a bunch of manual work. Vulnerable out of the box, but can be configured to be better than Windows.

Apple: Ha. Snare talked about attacking the Apple boot process in 2012 - basically everything he described then is still possible. Apple recently hired the people behind Legbacore, so there's hope - but right now all shipping Apple hardware has no firmware support for UEFI Secure Boot and no TPM. This makes it impossible to provide any kind of boot attestation, and there's no real way you can verify that your system hasn't been compromised.

Now, to be fair, there's attacks that even Windows and properly configured Linux will still be vulnerable to. Firmware defects that permit modification of System Management Mode code can still be used to circumvent these protections, and the Management Engine is in a position to just do whatever it wants and fuck all of you. But that's really not an excuse to just ignore everything else. Improving the current state of boot security makes it more difficult for adversaries to compromise a system, and if we ever do get to the point of systems which aren't running any hidden proprietary code we'll still need this functionality. It's worth doing, and it's worth doing now.

[1] Well, except Ubuntu's signed bootloader will happily boot unsigned kernels which kind of defeats the entire point of the exercise
[2] Initrds are built on the local machine, so we can't just ship signed images

comments

The following is a short summary of my open source work in December, following up on my first report in November.

Debian

• Uploaded mopidy-dirble 1.2.0-1: New upstream release.
• Created the pkg-mopidy Alioth team to set myself up for sharing the maintenance of Mopidy packages. As I upload new releases, I ll gather the git repositories of Debian packages related to Mopidy here. My intention is for the team to follow the DPMT policy closely.
• Sponsored: python-ase 3.9.1.4567-2, which adds Python 3 support.

Mopidy

• The feature/gst1 branch: Finished porting Mopidy from GStreamer 0.10 to PyGI and GStreamer 1.x. Merge of the branch is currently blocked on a single test failure (test_gapless) and issues with transitioning from one track to another with Mopidy-Spotify, which is the only backend using an appsrc for playback. The goal is for this branch to be part of Mopidy 1.2, which I hope to have in Debian/Ubuntu before the Ubuntu 16.04 import freeze February 18.
• The feature/py3-compat branch: I ve worked quite a bit on this private branch, frequently rebased on top of feature/gst1. Currently Mopidy starts without any crashes on Python 3 and the test suite is down to 262 failed and 1841 passed tests. My current thinking, is that this will become part of a Mopidy 2.0 release, which will support both Python 2.7 and 3.4+. As soon as most of Mopidy s extension ecosystem supports Python 2+3, a new Mopidy major release (3.0?) will drop Python 2 support.
• Merged a bunch of pull requests, both targeting the 1.1.2 bug fix release and the 1.2 feature release.

I didn t know Ian Murdock but the news about his passing left me with a very strange and sad feeling, because he started the project that creates the tool that I use every day in my work, and everyday in my communication with my family and friends, and everyday for anything computer related It s like if somebody puts a treasure in your hands and you got distracted looking at it and when you head up to look at the person and say Thank you , he s gone And, in the last years, Debian for me is not just my favorite tool , I ve been slowly getting involved in the community, known some people here and there, been able to put some work to try to improve some small parts, been able to work with other people as a team, and I ve been touched many times admiring how the Debianers work, how they talk and write, how they behave to each other and to the ones that reach the community for first time, and to the world, since most of the communication and work is public I ve felt myself helped, welcomed, encouraged, empowered. Not only in my computer related skills or the improved capabilities of my humble hardware. I ve felt myself helped, welcomed, encouraged and empowered in important areas of my life (understanding other points of view, caring about the ones that don t speak aloud, enjoying diversity and becoming flexible to make it flourish, making friends ). And I like to think that I try to emulate that and help, welcome, encourage, empower others too I m learning. Thanks Ian, for this alive and growing treasure that is Debian (the OS, the community), and thanks Debian, for the past, present and future miracles.
Filed under: My experiences and opinion Tagged: Communities, Contributing to libre software, Debian, English, Moving into free software

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):

• Released try.diffoscope.org, a hosted version of the diffoscope in-depth and content aware diff utility. Thanks to Bytemark for sponsoring the hardware.
• Announced travis.debian.net, a hosted script to easily test and build Debian packages on Travis CI.
• Wrote an Chrome extension for the FastMail web interface that reminds you if you neglect to attach a file if you mention one in the body. (Repo)
• Added graphical image comparison using to diffoscope using libcaca. (commit)
• Did further work on a free-software healthcare project.
• Added the ability to hide Zwift activities in my Strava Enhancement Suite Chrome extension. (#40)
• Updated the Django web framework documentation to discourage the use of filenames in /tmp with predictable names. (#5864)
• Corrected a Python 3.5-ism and a double-encoding issue in django-slack.
• Increased the size of the search form on codesearch.debian.net. (#59)
• Added support for filenames alongside the existing URL support for book cover images in my media database. (code)
• Corrected a trivial typo in FreeBSD's pkg package management tool. (#1353)
• Attended the 32nd Chaos Communication Congress.

---

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 21.25 hours on Debian LTS. During this time I worked on the following things:

• Sent a first patch and later an updated patch to modify DAK so that it can send the accept/reject mails to the signer of the upload instead of the maintainer. Details in #796784.
• Uploaded MySQL 5.5 compabitility fixes for phpmyadmin and postfix-policyd so that we could release MySQL 5.5 as an upgrade option MySQL 5.1 (see DLA 359-1).
• Released DLA 361-1 on bouncycastle after having gotten the green light from upstream.
• Released DLA 362-1 on dhcpd fixing three CVE.
• Released DLA 366-1 on arts fixing one CVE.
• Released DLA 367-1 on kdelibs fixing one CVE.
• Handled the LTS frontdesk for a whole week.
• Sponsored the upload of foomatic-filters for DLA 371-1.
• Filed #808256 and #808257 to get libnsbmp/libnsgif removed. Both packages had recent CVE and were sitting unused in Debian since their introduction 6 years ago
• Released DLA 372-1 announcing the end of support of virtualbox-ose.
• Updated git repository of debian-security-support to account for the former change and also took care of a few pending issues.
• Released DLA 376-1 on mono to fix one CVE.
• Added some initial DEP-8 tests to python-django that will help to ensure that a security update doesn t break the package.

Distro Tracker I put a big focus on tracker.debian.org work this month. I completed the switch of the mail interface from packages.qa.debian.org to tracker.debian.org and I announced the change on debian-devel-announce. The changes resulted in a few problems that I quickly fixed (like #807073) and some other failures seen only by me and that were generated by weird spam messages (did you know that a subject can t have a newline character but that it can be encoded and folded over multiple lines?). Related to that I fixed some services so that they send their mails to tracker.debian.org directly instead of relying on the old emails (they get forwarded for now but it would be nice to be able to get rid of that forward). I updated (with the help of Lucas Nussbaum) the service that forwards the Launchpad bugs to the tracker, I sent a patch to update the @packages.debian.org aliases (not yet applied), I updated the configuration of all git commit notice scripts in the Alioth collab-maint and python-modules project (many remain to be done). I asked Ubuntu s Merge-O-Matic to use the new emails as well (see LP 1525497). DAK and the Debian BTS still have to be updated, as of yet nobody reacted to my announce last but not least I updated many wiki pages which duplicated the instructions to setup the commit notice sent to the PTS. While on a good track I opted to tackle the long-standing RC bug that was plaguing tracker.debian.org (#789183), so I updated the codebase to rely on Twitter s bootstrap v4 instead of v2. I had to switch to something else for the icons since glyphicons is no longer provided as part of bootstrap and the actual license for the standalone version was not suitable for use. I opted for Github s Octicons. I made numerous little improvements while doing that (closing some bugs in the process) and I believe that the result is more pleasant to use. I also did a lot of bug triage and fixed a few small issues like the incomplete architecture list (#793547), or fixing a page used only by people with javascript disabled that was not working. Or the invalid links for packages still using CVS (ugh, see #561228). Misc packaging Django. After having added DEP-8 tests (as part of my LTS work, see above), I discovered that the current version in unstable did not pass its test suite so I filed the issue upstream (ticket 26016) and added the corresponding patch. And I encouraged others to update python-bcrypt in Debian to a newer version that would have worked with Django 1.9 (see #803096). I also fixed another small issue in Django (see ticket 26017 with my pull request that got accepted). I asked the release managers to consider accepting the latest 1.7.x version in jessie (see #807654) but I have gotten zero answer so far. And I m not the only one waiting an answer. It s a bit of a sad situation we still have a few weeks until the next point release but for once I do it in advance and I would love to have timely feedback. Last but not least, I started the maintaining the current LTS release (1.8.x) in jessie-backports. Tryton. I upgraded to Tryton 3.8 and discovered an issue that I filed in #806781. I sponsored 5 new tryton modules for Matthias Behrle (who is DM) as well as one security upload (for CVE-2015-0861). Debian Handbook. I uploaded a new version to Debian Unstable and requested (to the release managers) the permission to upload a backport of it to jessie so that jessie has a version of the package that documents jessie and not wheezy contrary to my other Django request, this one should be non-controversial but I also have had zero answer so far, see #807515. Misc. I filed #808583 when sbuild stopped working with Perl 5.22. I handled #807860 on publican, I found the corresponding upstream ticket and discovered a work around with the help of upstream (see here). Kali related work I reported a bug to #debian-apt about apt miscalculating download size (ending up with 18 EB!) which resulted in a fix here in version 1.1.4. Installing a meta-package that needed more than 2GB was no longer possible without this fix and we have a kali-linux-all metapackage in that situation that gets regularly installed in a Jenkins test. I added captcha support to Distro Tracker and enabled this feature on pkg.kali.org. I filed #808863 against uhd-host because it was not possible to install the package in a systemd-nspawn s managed chroot where /proc is read-only. And we started using this to test dist-upgrade from one version of Kali to the next Thanks See you next month for a new summary of my activities.

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

With a heavy heart Debian mourns the passing of Ian Murdock, stalwart proponent of Free Open Source Software, Father, Son, and the 'ian' in Debian. Ian started the Debian project in August of 1993, releasing the first versions of Debian later that same year. Debian would go on to become the world's Universal Operating System, running on everything from embedded devices to the space station. Ian's sharp focus was on creating a Distribution and community culture that did the right thing, be it ethically, or technically. Releases went out when they were ready, and the project's staunch stance on Software Freedom are the gold standards in the Free and Open Source world. Ian's devotion to the right thing guided his work, both in Debian and in the subsequent years, always working towards the best possible future. Ian's dream has lived on, the Debian community remains incredibly active, with thousands of developers working untold hours to bring the world a reliable and secure operating system. The thoughts of the Debian Community are with Ian's family in this hard time. His family has asked for privacy during this difficult time and we very much wish to respect that. Within our Debian and the larger Linux community condolences may be sent to in-memoriam-ian@debian.org where they will be kept and archived.

Con el coraz n compungido, Debian lamenta el fallecimiento de Ian Murdock, firme partidario del software libre y abierto, padre, hijo y el 'ian' en Debian. Ian empez el proyecto en agosto de 1993, publicando la primera versi n de Debian m s tarde en el mismo a o. Debian se convertir a as en el sistema operativo universal para el mundo, funcionando en cualquier dispositivo, desde sistemas embebidos hasta la estaci n espacial. Ian se centr en crear una distribuci n y una cultura de comunidad que hiciera lo correcto tanto en lo tico como en lo t cnico. Publicar cuando est listo y una postura firme sobre la libertad de software son las reglas de oro en el mundo del software libre y de c digo abierto. La devoci n le gui en su trabajo, tanto en Debian como en los a os posteriores, siempre trabajando hacia un futuro lo mejor posible. El sue o de Debian est vivo, la comunidad permanece incre blemente activa con miles de desarrolladores que trabajan incontables horas para ofrecer un sistema operativo seguro y confiable. La comunidad de Debian da el p same a la familia en este momento tan dif cil. Su familia nos ha pedido discreci n durante estos momentos dif ciles y deseamos respetarlo. Desde dentro de Debian y de la amplia comunidad de Linux podemos expresar nuestras muestras de condolencia a in-memoriam-ian@debian.org, donde ser n guardadas y archivadas.

Linux kernel modules often have options that can be set. Here's how to make use of them on Debian-based systems, using the i915 Intel graphics driver as an example. To get the list of all available options:

modinfo -p i915

To check the current value of a particular option:

cat /sys/module/i915/parameters/enable_ppgtt

To give that option a value when the module is loaded, create a new /etc/modprobe.d/i915.conf file and put the following in it:

options i915 enable_ppgtt=0

and then re-generate the initial RAM disks:

update-initramfs -u -k all

Alternatively, that option can be set at boot time on the kernel command line by setting the following in /etc/default/grub:

GRUB_CMDLINE_LINUX="i915.enable_ppgtt=0"

and then updating the grub config:

update-grub2

During our development sprint at 32c3 [1] and remote, we managed to get our--long awaited--mailing list server online:

• Arctica Project's Announcements Mailing List
• Arctica Project's Developers' Mailing List
• Arctica Project's SCM Mirroring Mailing List

Happy subscribing to those who are interested in remote desktop computing on Linux. Disclaimer: Please note that the Arctica Project is still in its infancy and we hope to have first releases during the upcoming year. Also we actively and intensively continue maintenance of what was formerly known as NX (version 3) [2]. light+love
Mike [1] https://events.ccc.de/category/32c3/ (traditionally down during the event)
[2] https://github.com/ArcticaProject/nx-libs

As of a few minutes ago, the old weblog on christoph-egger.org is past. I've added redirects for all the entries to the new one at weblog.siccegge.de.if you find any dead links please contact me so I can fix it up. Note that comments are gone. I'll try to include the already present comments on the new blog some time in the future. Not sure if I will ever add a comment function again (though chronicle seems to have some support for that)

I made a change recently on the gjay program. gjay is a gtk program that basically analyzes your music and makes playlists. There is a gui frontend and a analyzer back-end and they communicate through a pipe. One really useful debugging option gtk has is to make warnings fatal, so when gtk finds one it crashes at that point and you can use gdb to trap it. The flag is g-fatal-warnings. I have been updating gjay and initially it didn t have this option, so I needed to add the gtk options, which is a simple one-liner. But then gjay gave some odd errors about XCB. Often, but not every time gjay started on stderr the following cryptic messages appear:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
forktest: ../../src/xcb_io.c:274: poll_for_event: Assertion  !xcb_xlib_threads_sequence_lost' failed.

OK, so part of my init sequence was unhappy. The odd thing was it only appeared when I added the gtk options. I narrowed it down with some test code which displayed the error but stripped all the other parts out. What we got going on here is a simple gtk program. Line 11 with the gtk_get_option_group() was the line I added. The problem is that the child process is not quite setup and when the parent goes into gtk_main then you get those xcb errors. The options need to be parsed before the fork, because one of the options is to not fork (it just runs the child code directly and uses stdout with no GUI). Gjay is obviously a lot more complex than this, but follows the same pattern. There is the front-end looping through gtk_main and the back-end looping on g_main_run. The backend needs to use glib not gtk as there is a non-gui option which can be used. The solution is actually (but not obviously to me) in the documentation for gtk_get_option_group. The parameter for that function whether to open the default display when parsing the commandline arguments . Changing the TRUE to FALSE on line 11 stops XCB from complaining! The screen still appears fine but not more strange XCB messages.

In my old flat I had a couple of simple radio-controlled switches, which allowed me to toggle power to a pair of standing lamps - one at each side of the bed. This was very lazy, but also really handy and I've always been curious about automation.. When it comes to automation there seems to be three main flavours:

X10

The original standard, with stuff produced by many vendors and good Linux support. X10 supports two ways of sending/receiving commands - over the electrical wiring, and over RF.

Z-Wave

This is the newcomer, which despite that seems to be well-supported and extensible. It allows "measurements" to be sent/received in addition to the broadcast of events like "switch on", and "switch off".

Other systems - often lighting-centric

There are toy-things like the previously noted power-controlling things, there are also stand-alone devices from people like Philips with their philips hue system, but given how Philips recently crippled their devices to disable third-party bulbs I've no desire to use them. One company caught my eye though, Osram make a smart lightbulb and mini-hub to work with it.

So I bought one of the osram lightify systems, consisting of a magic box and a pair of lightbulbs. The box connects to your wifi, and gets an IP address. The IP address is then used by the application on your mobile phone (i.e. the magic box does the magic, not the bulbs). The phone application can be used to trigger "on", "off", "dim", "brighter", and the various colour-changing commands, as you would expect. You absolutely must use the phone-based application to do the setup, but after that the whole point was that I could automate things. I wanted to be able to setup my desktop computer to schedule events, and started hacking. I've written a simple Perl module to let me discover bulbs, and turn them off and on. No doubt it'll be on CPAN in the near future, once I can pick a suitable name for it:

$ ol --bridge=192.168.10.136 --list
hall       MAC:8418260000d9c70c RGBW:255,255,255,255 STATE:On
kitchen    MAC:8418260000cb433b RGBW:255,255,255,255 STATE:On
$ ol --bridge=192.168.10.136 --off=kitchen
$ ol --bridge=192.168.10.136 --list
hall       MAC:8418260000d9c70c RGBW:255,255,255,255 STATE:On
kitchen    MAC:8418260000cb433b RGBW:255,255,255,255 STATE:Off

The only niggle was the fiddly pairing, and the lack of any decent documentation. The code I wrote was loosely based on the python project python-lightify written by Mikael Magnusson. Also worth noting that the bridge/magic-box only exposes a single port so you can find the device on your VLAN by nmapping for port 4000:

$ nmap -v 192.168.10.0/24 -p 4000

The device doesn't seem to allow any network setup at all - it only uses DHCP. So you might want to make sure it gets assigned a stable IP. Anyway I'm going to bed. When I do so I'll turn the lights off with my mobile phone. Neat. In the future I will look at more complex automation, and I think Z-wave is the way I'll go. Right now I'm in a rented flat so replacing wall-switches, etc, is something I can't do. But the systems I've looked at seem neat, and this current setup will keep me amused for several months!

Not only do I keep incrementing version numbers faster than ever before, APT also keeps getting faster. But not only that, it also has some bugs fixed and the cache is now checked with a hash when opening. Important fix for 1.1.6 regression Since APT 1.1.6, APT uses the configured xz compression level. Unfortunately, the default was set to 9, which requires 674 MiB of RAM, compared to the 94 MiB required at level 6. This caused the test suite to fail on the Ubuntu autopkgtest servers, but I thought it was just some temporary hickup on their part, and so did not look into it for the 1.1.7, 1.1.8, and 1.1.9 releases. When the Ubuntu servers finally failed with 1.1.9 again (they only started building again on Monday it seems), I noticed something was wrong. Enter git bisect. I created a script that compiles the APT source code and runs a test with ulimit for virtual and resident memory set to 512 (that worked in 1.1.5), and let it ran, and thus found out the reason mentioned above. The solution: APT now defaults to level 6. New Features APT 1.1.8 introduces /usr/lib/apt/apt-helper cat-file which can be used to read files compressed by any compressor understood by APT. It is used in the recent apt-file experimental release, and serves to prepare us for a future in which files on the disk might be compressed with a different compressor (such as LZ4 for Contents files, this will improve rred speed on them by factor 7). David added a feature that enables servers to advertise that they do not want APT to download and use some Architecture: all contents when they include all in their list of architectures. This is to allow archives to drop Architecture: all packages from the architecture-specific content files, to avoid redundant data and (thus) improve the performance of apt-file. Buffered writes APT 1.1.9 introduces buffered writing for rred, reducing the runtime by about 50% on a slowish SSD, and maybe more on HDDs. The 1.1.9 release is a bit buggy and might mess up things when a write syscall is interrupted, this is fixed in 1.1.10. Cache generation improvements APT 1.1.9 and APT 1.1.10 improve the cache generation algorithms in several ways: Switching a lookup table from std::map to std::unordered_map, providing an inline isspace_ascii() function, and inlining the tolower_ascii() function which are tiny functions that are called a lot. APT 1.1.10 also switches the cache s hash function to the DJB hash function and increases the default hash table sizes to the smallest prime larger than 15000, namely 15013. This reduces the average bucket size from 6.5 to 4.5. We might increase this further in the future. Checksum for the cache, but no more syncs Prior to APT 1.1.10 writing the cache was a multi-part process:

1. Write the the cache to a temporary file with the dirty bit set to true
2. Call fsync() to sync the cache
3. Write a new header with the dirty bit set to false
4. Call fsync() to sync the new header
5. (Rename the temporary file to the target name)

The last step was obviously not needed, as we could easily live with an intact cache that has its dirty field set to false, as we can just rebuild it. But what matters more is step 2. Synchronizing the entire 40 or 50 MB takes some time. On my HDD system, it consumed 56% of the entire cache generation time, and on my SSD system, it consumed 25% of the time. APT 1.1.10 does not sync the cache at all. It now embeds a hashsum (adler32 for performance reasons) in the cache. This helps ensure that no matter what parts of the cache are written in case of some failure somewhere, we can still detect a failure with reasonable confidence (and even more errors than before). This means that cache generation is now much faster for a lot of people. On the bad side, commands like apt-cache show that previously took maybe 10 ms to execute can now take about 80 ms. Please report back on your performance experience with 1.1.10 release, I m very interested to see if that works reasonably for other people. And if you have any other idea how to solve the issue, I d be interested to hear them (all data needs to be written before the header with dirty=0 is written, but we don t want to sync the data). Future work We seem to have a lot of temporary (?) std::string objects during the cache generation, accounting for about 10% of the run time. I m thinking of introducing a string_view class similar to the one proposed for C++17 and make use of that. I also thought about calling posix_fadvise() before starting to parse files, but the cache generation process does not seem to spend a lot of its time in system calls (even with all caches dropped before the run), so I don t think this will improve things. If anyone has some other suggestions or patches for performance stuff, let me know.
Filed under: Debian, Ubuntu

24 Dec. 63 Dear Uncle Ron and Aunt Helen, It has been quite awhile since I have written you folks. I am not too much of one for writing, and when I do write, I keep putting it off, and putting it off; and the next thing you know, the weeks turn into months and then the months into years. I haven't sent any Christmas cards, so at this time I'll offer my best wishes for the season to you. It is Christmas Eve and I am working tonight. I will also work New Year's eve and day. It really doesn't seem like Christmas here, and there isn't that much to do in the evening's; So I'm just as well off working. As I had mentioned, I had intended to send you some coins from Korea but I believe that I put them in with a package that I had sent to Mom and told her to give them to you. In any event, here are some in this box. The Korean coin with the 10 on it is 10 Won, and worth about $.0769. The large copper coin is Japanese ( 10 Yen) and about 2.8 Wait! I was wrong on the Korean coins.They are 10 Hwan which is the old money. When they Changed to Won, they made 10 Hwan equal to 1 Won. (Sounds confusing and tongue-tying, doesn't it?) So these 10 copper pieces with the 10 on them altogether are only worth 7 / The Viet Namese coins with the former president Diem picture on them are soon being taken out of circulation. ( Since he was overthrown and killed, they are going to replace the money also.) The small pieces marked 1 dong are 1 piastre; also called one Viet Namese dollar. 1 piastre is about .7 . I also recall sending some coins home in my hold baggage. I'll tell Mom to look for them and give them to you. Now that I look back on it, the year I spent in Korea wasn't bad. It was difficult at first having to work for an arrogant Jew boss, but after a few months I got out of his office and was on my own working directly for the army people ( U.S.) The country of Korea isn't too bad. As you can see on the coins they were in the year 4294 last year. It is surprising for a civilization to be that far along in years and still live under very primitive conditions. Going from Korea to Japan is like going from the dark ages into the future science fiction world. Those people are really progressing in Japan. I spent several days in Japan after I left Korea. Then I went to Honolulu for almost a month. Then I went back to Japan for Leave for 3 weeks and then down here to Viet Nam in October. They were building like crazy in Japan to get ready for the Olympics. Working 4 hours a day, 7 days a week on construction. You could drive into Tokyo early in the evening and return late in the night and find the road you had gone in on was now completely torn away. And downtown Tokyo is vey nice. Lots of modern building and just about any modern gadget you can think of. I really like their cooking also. Their Kobe Beef is excellent. In this beef, the cattle are pampered from the time they are born until they are slaughtered. They massage them, feed them beer, and let them live a lazy life. I would really like to work a year or two in Japan. The hot baths and big tubs are also great. Only it is almost impossible to stand the hot temperatures that they can. Westerners always have to add quite a lot of cold water before they can get in the tub. The Viet Namese people are much dirtier than the Japanese or Koreans. They don't have any hot baths here in Viet Nam. In fact, the majority of hotels ( built by the French) don't even have hot water in them. The Korean houses don't look like much from the outside, but inside they are spotlessly clean. The older Japanese buildings look nic efrom the outside and are also clean inside. I am here in the town of Nha Trang. It is a small town on the coast of the China Sea. I like it here. My hotel is less than a hundred yards from the beach. We are now in the winter season also, but it just got a little cooler from having winds the past few weeks. This afternoon as we came to work there were all sorts of people in swimming. Lobster is also plentiful here and I eat quite a bit of it. Most of the restaurant make a creamed corn soup with lots of chunks of crab meat in it. This is very good. Being out here in Nha Trang, we missed the coup d'etat. Things were quiet here and the only way we knew what was happening was to listen to the radio and talk to our co-workers of our radio system in Saigon. When they lifted martial law and the curfew in Saigon, it took them several days later to follow suit here. There seems to be a noticed improvement since the coup. The people in general seem much happier and there appears to be much more general activity going on. Well, I guess that's about it for now. I think I may have some Korean Won notes back in my room and I'll check and enclose them if I can find them. Say hello to Ira & family when you see them, and also to Aunt Marie if she is still there with you. 'Bye for now Your nephew PS The Viet Namese coins with 50 XU on them are piastres.

Since the last version 0.0.9 on Debian, I have made some changes until version 0.0.14. The version 0.0.15 is only to include a fix for the new findutils. I thank you to Andreas Metzler for the fix and the prompt NMU. The files are here, take notice about the replaced ~ in the original by _: switchconf_0.0.15.orig.tar.xz switchconf_0.0.15-1_wip1.debian.tar.xz switchconf_0.0.15-1_wip1_all.deb If you need the dsc file, just ask me. Here comes the changelog since 0.0.9, without the lastest NMU:

switchconf (0.0.15-1~wip1) UNRELEASED; urgency=low
  * New upstream version:
    * Replace 'find -perm +1' by 'find -perm /1', thank you Andreas
      Metzler for the patch and the NMU.
  * Add systemd service file, thank you Felipe Sateler for reviewing it.
  * Bump standards-version to 3.9.6, no changes needed.
  * New maintainer email address.
 -- Jose M Calhariz <jose@calhariz.com>  Tue, 29 Dec 2015 19:59:07 +0000
switchconf (0.0.14-1) UNRELEASED; urgency=low
  * Force the use of bash, instead of a POSIX shell.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 24 Aug 2014 04:37:04 +0100
switchconf (0.0.13-2) UNRELEASED; urgency=low
  * Add Homepage field pointing to alioth page of the project
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 18:01:07 +0000
switchconf (0.0.13-1) wheezy; urgency=low
  * New upstream version:
    * Distribution tar is now compressed by xz
  * Change to source format 3.0 (quilt)
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 15:56:31 +0000
switchconf (0.0.12-1) wheezy; urgency=low
  * Fixed some typos on switchconf
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 15:39:09 +0000
switchconf (0.0.11-1) wheezy; urgency=low
  * New upstream version:
    * Makefile: add target dist-exp to build distribution files.
    * Add flag -f with the path to the configuration file.
  * Update debian/rules to version 0.24.
  * Update debian/control with new name and email address of Maintainer.
  * Update copyright.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 16 Feb 2014 18:04:22 +0000
switchconf (0.0.10-1) UNRELEASED; urgency=low
  * New upstream version:
    * Fix return code on error.
    * Use syslog system to report errors.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Thu, 16 Jan 2014 20:23:46 +0000

Today I was wondering about converting a pdf made from scan of a book into djvu, hopefully to reduce the size, without too much loss of quality. My initial experiments with pdf2djvu were a bit discouraging, so I invested some time building gsdjvu in order to be able to run djvudigital. Watching the messages from djvudigital I realized that the reason it was achieving so much better compression was that it was using black and white for the foreground layer by default. I also figured out that the default 300dpi looks crappy since my source document is apparently 600dpi. I then went back an compared djvudigital to pdf2djvu a bit more carefully. My not-very-scientific conclusions:

• monochrome at higher resolution is better than coloured foreground
• higher resolution and (a little) lossy beats lower resolution
• at the same resolution, djvudigital gives nicer output, but at the same bit rate, comparable results are achievable with pdf2djvu.

Perhaps most compellingly, the output from pdf2djvu has sensible metadata and is searchable in evince. Even with the --words option, the output from djvudigital is not. This is possibly related to the error messages like

Can't build /Identity.Unicode /CIDDecoding resource. See gs_ciddc.ps .

It could well be my fault, because building gsdjvu involved guessing at corrections for several errors.

• comparing GS_VERSION to 900 doesn't work well, when GS_VERSION is a 5 digit number. GS_REVISION seems to be what's wanted there.
• extra declaration of struct timeval deleted
• -lz added to command to build mkromfs

Some of these issues have to do with building software from 2009 (the instructions suggestion building with ghostscript 8.64) in a modern toolchain; others I'm not sure. There was an upload of gsdjvu in February of 2015, somewhat to my surprise. AT&T has more or less crippled the project by licensing it under the CPL, which means binaries are not distributable, hence motivation to fix all the rough edges is minimal.

Version	kilobytes per page	position in figure
Original PDF	80.9	top
pdf2djvu --dpi=450	92.0	not shown
pdf2djvu --monochrome --dpi=450	27.5	second from top
pdf2djvu --monochrome --dpi=600 --loss-level=50	21.3	second from bottom
djvudigital --dpi=450	29.4	bottom

initramfs-tools version 0.121~rc2 and dracut version 044+3-2 have moved most of what was in their main binary packages into a 'core' package (dracut-core, initramfs-tools-core), leaving only automation hooks in the main package. The core packages can be coinstalled without conflicts and without creating any initramfs images at installation time. If you're been wondering how they compare but were afraid to break your system by overwriting your current working initramfs, now is the time to try the other option. Testing dracut, for initramfs-tools users

1. Install dracut-core from unstable.
2. Make an alternate initramfs image by running:
   dracut /boot/initrd.img-$(uname -r).dracut
3. Add an entry to the boot loader configuration that uses your current kernel and the alternate initramfs image. (In GRUB, you can do this interactively at boot time.)
4. Reboot through the new boot entry.
5. In case of problems, check the dracut(8) and dracut.conf(5) manual pages.

By default, dracut creates an initramfs suitable for the current hardware, which will not boot if you move the disk to a system that requires different drivers. This is controlled by the hostonly configuration variable or --hostonly command-line option. Testing initramfs-tools, for dracut users

1. Install initramfs-tools-core from experimental.
2. Make an alternate initramfs image by running:
   mkinitramfs -o /boot/initrd.img-$(uname -r).i-t
3. Add an entry to the boot loader configuration that uses your current kernel and the alternate initramfs image. (In GRUB, you can do this interactively at boot time.)
4. Reboot through the new boot entry.
5. In case of problems, check the mkinitramfs(8) and initramfs.conf(5) manual pages.

By default, initramfs-tools creates an initramfs suitable for most hardware, which will still boot if you move the disk to a system that requires different drivers. This is controlled by the MODULES configuration variable.

LXQt is a Qt lightweight desktop the Qt port of LXDE. Packages exist in Debian albeit without a top level metapackage or task package to make installing it easier. So I wrote up a simple-ish vmdebootstrap call:
$ sudo vmdebootstrap --image lxqt.img --size=5G --package=lxqt-panel --package=libqt5xcbqpa5 --package=qterminal --package=openbox --package=xdm --package=lxqt-session --package=lxqt-about --package=lxqt-policykit --package=lxqt-globalkeys --package=lxqt-notificationd --package=lxqt-sudo --package=dbus-x11 --package=lxqt-admin --package=lxqt-runner --package=lxqt-config --package=task-desktop --package=locales --package=xserver-xorg-core --package=oxygen-icon-theme --grub --distribution=unstable --mirror=http://mirror.bytemark.co.uk/debian --configure-apt --enable-dhcp --serial-console --sudo --verbose --owner=neil --user='neil/neil'
(You ll need to adapt the last two commands to be a real user.) This uses xdm instead of lxdm as this tests LXQt without having any GTK+ dependencies installed. lxdm does give a nicer experience at the cost of needing GTK+. YMMV. Note the explicit additions:--package=libqt5xcbqpa5 --package=dbus-x11 as debootstrap does not follow Recommends, libqt5xcbqpa5 needs to be specified explicitly or the desktop will fail to start. dbus-x11 is also needed to get things working. task-desktop adds the Debian artwork and needs to be in the list of packages passed to debootstrap so that the Recommends of the task packages are not selected. (Note that I have so far failed to get LXQt to use the Debian artwork as a desktop background.) So, what is it like? Well alpha is how I might describe it. Not in terms of stability, more in terms of functionality. I do have a second install using lxdm which has been tweaked but it depends on your objective. If your aim is to not have GTK+ but not have KDE, then LXQt is a beginning only. In particular, if you really are intent on not having GTK+ at all, your choice of web browser is somewhat limited, to lynx. (There s no bare Qt file manager in Debian pcmanfm-qt depends on libfm-modules which uses GTK+ nor a bare text editor despite this being one of the simplest examples of a QApplication). There is a large gap in the software availability which is Qt but not KDE, despite the power and flexibility of Qt itself. (I ve written applications using Qt directly before, it is much more flexible and configurable than GTK+). So there would seem to be a reason why a metapackage and a task package do not yet exist, there is a lot more to do. I m happy to mix GTK+ applications, so my test environment can use iceweasel, chromium, leafpad and thunar. Overall, this was an interesting diversion prompted by a separate discussion about the merits and controversies of GTK+, GNOME etc. I failed to work out why the icon theme works if lxdm was installed but not with xdm (so there s a missing package but I m not yet sure exactly which), so the screenshot is more bare than I expected. With iceweasel installed and various other tweaks:
Finally, note #809339 I have local changes which are being tested to use systemd-networkd but currently the masking of PredictableInterfaceNames as documented does not work, so some editing of /etc/network/interfaces.d/setup (or enable systemd-networkd yourself and add a suitable file to /etc/systemd/network/) will be needed to get a working network connection in the VM.