Search Results: "tar"

1 November 2017

James McCoy: Monthly FLOSS activity - 2017/10 edition

Debian subversion vim
libvterm
pangoterm
vim-gnupg
neovim
vim

31 October 2017

Paul Wise: FLOSS Activities October 2017

Changes

Issues

Review

Administration
  • Debian: respond to mail debug request, redirect hardware access seeker to guest account, redirect hardware donors to porters, redirect interview seeker to DPL, reboot system with dead service
  • Debian mentors: security updates, reboot
  • Debian wiki: upgrade search db format, remove incorrect bans, whitelist email addresses, disable accounts with bouncing email, update email for accounts with bouncing email
  • Debian website: remove need for a website rebuild
  • Openmoko: restart web server, set web server process limits, install monitoring tool

Sponsors The talloc/cmocka uploads and the remmina issue were sponsored by my employer. All other work was done on a volunteer basis.

Chris Lamb: Free software activities in October 2017

Here is my monthly update covering what I have been doing in the free software world in October 2017 (previous month):
Reproducible builds

Whilst anyone can inspect the source code of free software for malicious flaws, most software is distributed pre-compiled to end users. The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced either maliciously or accidentally during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. I have generously been awarded a grant from the Core Infrastructure Initiative to fund my work in this area. This month I:


I also made the following changes to our tooling:
diffoscope

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues.

  • Improve names in output of "internal" binwalk members. (#877525).
  • Don't crash on malformed md5sums files. (#877473).
  • Omit misleading "any of" prefix when only complaining about a single module on import. [...]
  • Adjust tests as ps2ascii now varies its output on timezone. [...]

strip-nondeterminism

strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build.

  • Clojure considers .class file to be stale if it shares the same timestamp of the .clj. We thus adjust the timestamps of the .clj to always be younger. (#877418).
  • Print a message in --verbose mode if no canonical time was specified. [...]

buildinfo.debian.net

buildinfo.debian.net is my experiment into how to process, store and distribute .buildinfo files after the Debian archive software has processed them.

  • Always show SHA-256 checksums, regardless of the browser viewport size. [...]
  • Add an API endpoint to fetch specific .buildinfo files for a certain package/version/architecture. [...]


Debian My activities as the current Debian Project Leader are covered in my "Bits from the DPL" email to the debian-devel-announce mailing list.
Patches contributed
  • devscripts: Please print the actual arguments debuild makes to Lintian. (#880124)
  • hw-detect: Drop reference to floppy disks; it's almost 2018. (#880122)
  • debci:
    • Use deb.debian.org over http.debian.net. (#879654)
    • Document how to use an alternative mirror. (#879655)
Debian LTS

This month I have been paid to work 18 hours on Debian Long Term Support (LTS). In that time I did the following:
  • "Frontdesk" duties, triaging CVEs, etc.
  • Followed up on a large number of upstream "pings" that have been left dormant.
  • Issued DLA 1121-1 to fix an out-of-bounds read vulnerability in curl where a malicious FTP server could abuse this to prevent clients from interacting with it.
  • Issued DLA 1123-1 for the "Go" programming language where an attacker could generate a MIME request such that the server ran out of file descriptors.
  • Issued DLA 1126-1 for the libxfont font selection and rasterisation library, correcting two vulnerabilities, both involving the library being tricked into reading invalid/random memory.
  • Issued DLA 1134-1 for sdl-image1.2, an image loading library. A maliciously-crafted .xcf file could cause a stack-based buffer overflow resulting in potential code execution.
Uploads
  • python-django:
    • 2.0~beta1-1 New upstream 2.x release.
    • 1.11.6-1 New upstream bugfix release.
  • gunicorn (19.6.0-10+deb9u1) Prepared a release for stable to avoid a runtime dependency on a compiler. (#877722)
  • redis:
    • 4:4.0.2-3:
      • Drop the Debian-specific /etc/redis/redis-server.pre-up.d (etc.) hooks and remove them if unchanged.
      • Include systemd redis-server@.service and redis-sentinel@.service template files to easily run multiple Redis instances. (#877702)
      • Patch redis.conf and sentinel.conf with quilt instead of maintaining our own versions under debian/.
    • 4:4.0.2-4:
      • Add input validity checking to cluster config slot numbers to fix CVE-2017-15047. (#878076)
      • Drop debian/bin/generate-parts now we aren't calling it.
      • Correct Bash-ism in NEWS file.
    • 4:4.0.2-5: Replace the existing patch for CVE-2017-15047 with an upstream-blessed version that covers another case.
  • redisearch (0.21.3-5) Initial release.
  • docbook2man (2.0.0-40) Correct spelling mistakes in binaries and other misc packaging tidying.
  • python-redis (2.10.6-1) New upstream release.
  • bfs (1.1.3-1) New upstream release.
FTP Team

As a Debian FTP assistant I ACCEPTed 103 packages: amcheck, argagg, binutils, blockui, bro-pkg, chkservice, citus, django-axes, docker-containerd, doctest, dtkwidget, duktape, feed2exec, fontforge, fonttools, gcc-8, gcc-8-cross, generator-scripting-language, gitgraph.js, haskell-uri-encode, hoel, iniparser, its, jquery-areyousure, kodi, libcatmandu-mods-perl, libcatmandu-template-perl, libcatmandu-xml-perl, libcatmandu-xsd-perl, libcode-tidyall-plugin-sortlines-naturally-perl, libgdamm5.0, libinfinity, libmods-record-perl, libreoffice-dictionaries, libset-intervaltree-perl, libsodium, linux, linux-grsec, ltsp-manager, lxqt-themes, mailman3-core, measurement-kit, mini-buildd, musescore, node-babel, node-babel-eslint, node-babel-loader, node-babel-plugin-add-module-exports, node-babel-plugin-transform-define, node-gulp-newer, node-regenerate-unicode-properties, node-regexpu-core, node-regjsparser, node-unicode-data, node-unicode-loose-match, openjdk-9, orafce, pgaudit, pgsql-ogr-fdw, pk4, postgresql-mysql-fdw, powa-archivist, python-azure-devtools, python-colormap, python-darkslide, python-dotenv, python-karborclient, python-logfury, python-lupa, python-marshmallow, python-murano-pkg-check, python-octaviaclient, python-pathspec, python-pgpy, python-pydub, python-randomize, python-sabyenc, python-searchlightclient, python-stestr, python-subunit2sql, python-twitter, python-utils, python-wsgilog, r-cran-bindr, r-cran-desc, r-cran-hms, r-cran-readstata13, r-cran-rprojroot, r-cran-wikidatar, r-cran-wikipedir, r-cran-wikitaxa, repmgr, requests-file, resteasy3.0, sdl-kitchensink, stardicter, systemd-el, thunderbird, tomcat8.0, uwsgi-plugin-luajit, uwsgi-plugin-mongo, uwsgi-plugin-php & uwsgi-plugin-v8. I additionally filed 3 RC bugs against packages that had incomplete debian/copyright files against: fonttools, generator-scripting-language & libsodium.

Petter Reinholdtsen: Web services for writing academic LaTeX papers as a team

I was surprised today to learn that a friend in academia did not know there are easily available web services available for writing LaTeX documents as a team. I thought it was common knowledge, but to make sure at least my readers are aware of it, I would like to mention these useful services for writing LaTeX documents. Some of them even provide a WYSIWYG editor to ease writing even further. There are two commercial services available, ShareLaTeX and Overleaf. They are very easy to use. Just start a new document, select which publisher to write for (ie which LaTeX style to use), and start writing. Note, these two have announced their intention to join forces, so soon it will only be one joint service. I've used both for different documents, and they work just fine. While ShareLaTeX is free software, while the latter is not. According to a announcement from Overleaf, they plan to keep the ShareLaTeX code base maintained as free software. But these two are not the only alternatives. Fidus Writer is another free software solution with the source available on github. I have not used it myself. Several others can be found on the nice alterntiveTo web service. If you like Google Docs or Etherpad, but would like to write documents in LaTeX, you should check out these services. You can even host your own, if you want to. :)

Norbert Preining: Debian/TeX Live 2017.20171031-1

Halloween is here, time to upload a new set of scary packages of TeX Live. About a month has passed, so there is the usual big stream up updates. There was actually an intermediate release to get out some urgent fixes, but I never reported the news here. So here are the accumulated changes and updates. My favorite this time is wallcalendar, a great class to design all kind of calendars, it looks really well done. I immediately will start putting one together. On the font side there is the new addition coelacanth. To quote from the README: Coelacanth is inspired by the classic Centaur type design of Bruce Rogers, described by some as the most beautiful typeface ever designed. It aims to be a professional quality type family for general book typesetting. And indeed it is beautiful! Other noteworthy addition is the Spark font that allows creating sparklines in the running text with LaTeX. Enjoy. New packages algobox, amscls-doc, beilstein, bib2gls, coelacanth, crossreftools, dejavu-otf, dijkstra, ducksay, dynkin-diagrams, eqnnumwarn, fetchcls, fixjfm, glossaries-finnish, hagenberg-thesis, hecthese, ifxptex, isopt, istgame, ku-template, limecv, mensa-tex, musicography, na-position, notestex, outlining, pdfreview, spark-otf, spark-otf-fonts, theatre, unitn-bimrep, upzhkinsoku, wallcalendar, xltabular. Updated packages acmart, amsmath, animate, arabluatex, arara, babel, babel-french, bangorexam, baskervillef, beebe, biblatex-philosophy, biblatex-source-division, bibletext, bidi, bxjaprnind, bxjscls, bxpapersize, bytefield, classicthesis, cochineal, complexity, cooking-units, curves, datetime2-german, dccpaper, doclicense, docsurvey, eledmac, epstopdf, eqparbox, esami, etoc, fbb, fei, fithesis, fmtcount, fnspe, fonts-tlwg, fontspec, genealogytree, glossaries, glossaries-extra, hecthese, hepthesis, hvfloat, ifplatform, ifptex, inconsolata, jfmutil, jsclasses, ketcindy, knowledge, koma-script, l3build, l3experimental, l3kernel, l3packages, langsci, latex2man, latexbug, lato, leadsheets, libertinust1math, listofitems, luatexja, luatexko, luatodonotes, lwarp, markdown, mcf2graph, media9, newtx, novel, numspell, ocgx2, overpic, philokalia, phonenumbers, platex, poemscol, pst-exa, pst-geometrictools, pst-ovl, pst-plot, pst-pulley, pst-tools, pst-vehicle, pst2pdf, pstool, pstricks, pstricks-add, pxchfon, pxjahyper, quran, randomlist, rec-thy, reledmac, robustindex, scratch, skrapport, spectralsequences, tcolorbox, tetex, tex4ht, texcount, texdoc, tikzducks, tikzsymbols, toptesi, translation-biblatex-de, unicode-math, updmap-map, uplatex, widetable, xcharter, xepersian, xetexko, xetexref, xsim, zhlipsum.

30 October 2017

Russell Coker: Logic of Zombies

Most zombie movies feature shuffling hordes which prefer to eat brains but also generally eat any human flesh available. Because in most movies (pretty much everything but the 28 Days Later series [1]) zombies move slowly they rely on flocking to be dangerous. Generally the main way of killing zombies is severe head injury, so any time zombies succeed in their aim of eating brains they won t get a new recruit for their horde. The TV series iZombie [2] has zombies that are mostly like normal humans as long as they get enough brains and are smart enough to plan to increase their horde. But most zombies don t have much intelligence and show no signs of restraint so can t plan to recruit new zombies. In 28 Days Later the zombies aren t smart enough to avoid starving to death, in contrast to most zombie movies where the zombies aren t smart enough to find food other than brains but seem to survive on magic. For a human to become a member of a shuffling horde of zombies they need to be bitten but not killed. They then need to either decide to refrain from a method of suicide that precludes becoming a zombie (gunshot to the head or jumping off a building) or unable to go through with it. Most zombie movies (I think everything other than 28 Days Later) has the transition process taking some hours so there s plenty of time for an infected person to kill themself or be killed by others. Then they need to avoid having other humans notice that they are infected and kill them before they turn into a zombie. This doesn t seem likely to be a common occurrence. It doesn t seem likely that shuffling zombies (as opposed to the zombies in 28 Days Later or iZombie) would be able to form a horde. In the unlikely event that shuffling zombies managed to form a horde that police couldn t deal with I expect that earth-moving machinery could deal with them quickly. The fact that people don t improvise armoured vehicles capable of squashing zombies is almost as ridiculous as all the sci-fi movies that feature infantry. It s obvious that logic isn t involved in the choice of shuffling zombies. It s more of a choice of whether to have the jump-scare aspect of 18 Days Later, the human-drama aspect of zombies that pass for human in iZombie, or the terror of a slowly approaching horrible fate that you can t escape in most zombie movies. I wonder if any of the music streaming services have a horror-movie playlist that has screechy music to set your nerves on edge without the poor plot of a horror movie. Could listening to scary music in the dark become a thing?
Related posts:
  1. Logic and Pants I just read an interesting post about proposed new laws...
  2. Water Dogs Good for Uplift? Update: I am now convinced that the Aquatic Ape theory...

Norbert Preining: Inconsistent version numbers in subversion

Update 2017-10-31: The developers of Subversion were a bit surprised, but it turned out to be a genuine bug. The bug has been fixed the same day. The TeX Live project uses Subversion as its main repository. Reasons for that there are many, see my blog post on svn and git. But today I realized that subversion is broken, badly broken, because one can easily end up with inconsistent version numbers. To understand why this is a problem, I restart from the already linked blog: Our packages have revision numbers based on the latest change revision of all the contained files. Since subversion has a linear history and central repository, this guarantees that in contrast to version numbers provided by authors the revision numbers are strictly increasing . Well, it turned out that this assumption was wrong. Because it is easy to trick subversion to have wrong revision numbers for files. Consider the following flow: In our case we have files listing other packages, and they are getting moved around at times. In this case one package was moved from one collection to another and back. Now, if user A does svn up between revision A+n and A+n+m, then the final revision in his checkout of file xxx will be A+n+m. But a user B that does NOT do svn up between A+n and A+n+m will end up with a final revision of A for file xxx in his checkout. And boooom, revisions are different, although the files are in sync with the server. I cannot grasp what the developers of subversion thought about here, but I consider it deeply broken by design. One more reason the rewrite all our distribution scripts to work with git instead of subversion.

29 October 2017

Niels Thykier: Building packages without (fake)root

Turns out that it is surprisingly easy to build most packages without (fake)root. You just need to basic changes:
  1. A way to set ownership to root:root of paths when dpkg-deb build constructs the binary.
  2. A way to have debhelper not do a bunch of (now) pointless chowns to root:root .
The above is sufficient for dpkg, debhelper, lintian, apt-file, mscgen, pbuilder and a long list of other packages that only provide paths owned by root:root . Obviously, packages differ and yours might need more tweaks than this (e.g. dh_usrlocal had to change behaviour to support this). But for me, the best part is that the above is not just some random prototype stuck in two git repos on alioth: Unfortunately, if you are working with games or core packages like shadow with need for static ownership different from root:root (usually with a setuid or setgid bit), then our first implementation does not support your needs at the moment[1]. We are working on a separate way to solve static ownership in a declarative way. [1] Note regarding /usr/local : If your package needs to provide directories there owned by root:staff with mode 02775, then dh_usrlocal can handle that. The non- root:root ownership here works because the directories are created in a maintainer script run as root during installation. Unfortunately, it cannot provide different ownership or modes with R != binary-targets at the moment.
Filed under: Debhelper, Debian

Russ Allbery: Review: Why We Sleep

Review: Why We Sleep, by Matthew Walker
Publisher: Scribner
Copyright: October 2017
ISBN: 1-5011-4433-2
Format: Kindle
Pages: 341
The world is full of theories, and corresponding books, about things that will make you healthier or prevent disease. Nearly all of them are scams, either intentional or created through the placebo effect and the human tendency to see patterns that don't exist. The rare ones that aren't have a certain pattern: they're grounded in our best understanding of biology, align with what our body wants to do anyway, have been thoroughly studied using proper testing methodology, and don't make money for powerful corporations. I'm fairly sure this is one of those rare ones that isn't a scam. And, if so, it's rather important and worth your attention. Matthew Walker is a professor of neuroscience and biology at the University of California at Berkeley, where he's the founder of the Center for Human Sleep Science. He's not a doctor; he started medical training, but (as he says in the book) found himself more attracted to questions than answers. He's a professional academic researcher who has been studying sleep for decades. This book is a combination of summary of the current state of knowledge of academic sleep research and a plea: get more sleep, because we're literally killing ourselves with the lack of it. Walker opens the book with a discussion of the mechanisms of sleep: how we biologically fall asleep and why, how this has changed over time, and how it changes with age. Along with that, he defines sleep: the REM and NREM sleep cycle that you may have already heard of, how it manifests itself in most people, and where dreams fit in. The second part then discusses what happens when you sleep, with a focus on what goes wrong when you don't. (Spoiler: A lot. Study after study, all cited and footnoted, has found connections between sleep and just about every aspect of mental and physical health.) The third part does the same for dreams, fitting them into the picture along with a scientific discussion of just what's going on during dreams. The fourth and final part tackles the problem: why don't we get enough sleep, and what can we do about it? I will warn in advance that this book will make you paranoid about your sleeping patterns. Walker has the missionary zeal of an academic who has sunk his teeth into something really important that society needs to take into account and will try to drown you in data, analysis, analogies, and sheer earnestness until you will believe him. He wants you to get at least seven, and preferably eight, hours of sleep a night. Every night, with as little variation as you can manage. Everyone, even if you think you're someone who doesn't need as much sleep (you're probably not). There's a ton of science here, a great popularization of a whole field of research, but this is also a book that's trying to get you to do something. Normally, that sort of book raises my shields. I'm not much of a believer in any book of the general genre of "most people are doing this basic part of life wrong, and should do it my way instead." But the hallmarks of good science are here: very widespread medical consensus, no corporate interest or obvious path to profit, and lots of studies (footnoted here, with some discussions of methodology although not the statistical details, which will require looking up the underlying studies and careful caveats where studies indicate correlation but may not find causes). And Walker makes the very telling point early in the book that nearly every form of life on the planet sleeps in one way or another (defined as a daily recurring period of time during which it doesn't respond to outside stimulus), which is a strong indicator of universal necessity. Given the vulnerability and loss of useful hours that come with sleep, one would expect some species to find an evolutionary path away from it if it were dispensable. But except for extremely short-lived species, we've never found a living creature that didn't sleep. Walker's argument for duration is also backed up by repeated studies on human capability before and after various quantities of sleep, and on studies of the sleep phases in various parts of the night. Study after study used six hours as the cutoff point and showed substantial deterioration in physical and mental capabilities even after only one night of short sleeping. (Reducing sleep to four hours is nearly catastrophic.) And, more worrisomely, that degradation is still measurable after "catching up" on sleep on subsequent nights. Sleeping in on weekends doesn't appear to fully compensate for the damage done by short-sleeping during the week. When Walker gets into the biological reasons for sleep, one starts to understand why it's so important. I think the part I found the most fascinating was the detailed analysis of what the brain is doing while you sleep. It's not inactive at all, even outside of REM sleep. Walker and other sleep researchers have done intriguing experiments showing how different parts of the sleep cycle transfer memories from short to long term storage, transfer physical skills into subconscious parts of the brain, discard short term memories that the conscious brain has tagged as being unwanted, and free up space for new knowledge acquisition. REM sleep appears to attempt to connect otherwise unrelated memories and bits of knowledge, inverting how association normally works in the brain, thus providing some concrete explanation for sleep's role in creativity. And (this research is fairly new), deep NREM sleep causes temporary physical changes in the brain that appear to be involved in flushing metabolic waste products away, including the plaque involved in Alzheimer's. The last part of the book is probably the most concretely useful: what can one practically do to get more sleep? There is quite a lot that's proven effective, but Walker starts with something else: sleeping pills. Here, you can almost see the lines drawn by a lawyer around what Walker should say. He stresses that he's not a medical doctor while laying out study after study that all point in the same direction: sleeping pills are a highly dangerous medical fraud that will shorten your lifespan for negligible benefit in helping you fall asleep, while limiting your brain's ability to enter true sleep. They're sedation, sedation is not sleep, and the four billion dollar sleeping pill market is literally making everything worse. The good news is there is an effective treatment for insomnia that works for many people; the better news is that it's completely free (although Walker does suggest some degree of medical supervision for serious insomnia so that some parts of it can be tailored to you). He walks through CBT-I (cognitive behavior therapy for insomnia), which is now the medically recommended primary treatment for insomnia, and takes apart the pieces to show how they line up with the results of sleep research studies. Alongside that are recommendations for improving sleep for people who don't have clinical insomnia but who aren't regularly getting the recommended amount of sleep. There are a lot of interesting bits here (and he of course talks about blue LED light and its relationship to melatonin cycles), but I think the most interesting for me was that you have to lower your core body temperature by a couple of degrees (Fahrenheit) to enter sleep. The temperature of your sleeping environment is therefore doubly important: temperature changes are one of the signals your body uses to regulate circadian rhythms (cold being a signal of night), and a colder sleeping area helps you lower your core body temperature so that you can fall asleep. (The average person does best with a sleeping room temperature of 65F, 18C.) There's even more in here: I haven't touched on Walker's attack on the US tendency to push high school start times earlier and earlier in the day (particularly devastating for teenagers, whose circadian rhythms move two hours later in the day than adults before slowly returning to an adult cycle). Or the serious problems of waking to an alarm clock, and the important benefits of the sleep that comes at the end of a full night's cycle. Or the benefits of dreams in dealing with trauma and some theories for how PTSD may interfere with that process. Or the effect of sleep on the immune system. Walker's writing style throughout Why We Sleep is engaging and clear, although sometimes too earnest. He really wants the reader to believe him and to get more sleep, and sometimes that leaks around the edges. One can also see the effort he's putting into not reading too much into research studies, but if there's a flaw in the science here, it's that I think Walker takes a few tentative conclusions a bit too far. (I'm sure these studies have the standard research problem of being frequently done on readily-available grad students rather than representative samples of the population, although the universality of sleep works in science's favor here.) Some of the recitations of research studies can get rather dry, and I once again discovered how boring I find most discussion of dreams, but for a first book written by an academic, this is quite readable. This is one of those books that I want everyone to read mostly so that they can get the information in it, not as much for the enjoyment of reading the book itself. I've been paying closer attention to my own sleep patterns for the last few years, and my personal experience lines up neatly with the book in both techniques to get better sleep and the benefits of that sleep. I'd already reached the point where I was cringing when people talk about regularly going on four or five hours of sleep; this is an entire book full of researched reasons to not do that. (Walker points out that both Reagan and Thatcher, who bragged about not requiring much sleep, developed Alzheimer's, and calls out Trump for making the same brag.) The whole book may not be of interest to everyone, but I think everyone should at least understand why the World Heath Organization recommends eight hours a night and labels shift work a probable carcinogen. And, as Walker points out, we should be teaching some of this stuff in school health classes alongside nutrition and sex education. Alas, Walker can't provide much advice on what I think is the largest robber of sleep: the constant time pressure of modern life, in which an uninterrupted nine hour sleep opportunity feels like an unaffordable luxury. Rating: 9 out of 10

28 October 2017

Steinar H. Gunderson: Introducing Narabu, part 4: Decoding

Narabu is a new intraframe video codec. You probably want to read part 1, part 2 and part 3 first. So we're at the stage where the structure is in place. How do we decode? Once we have the structure, it's actually fairly straightforward: First of all, we need to figure out where each slice starts and ends. This is done on the CPU, but it's mostly just setting up pointers, so it's super-cheap. It doesn't see any pixels at all, just lengths and some probability distributions (those are decoded on the CPU, but they're only a few hundred values and no FP math is involved). Then, we set up local groups of size 64 (8x8) with 512 floats of shared memory. Each group will be used for decoding one slice (320 blocks), all coefficients. Each thread starts off doing rANS decoding (this involves a lookup into a small LUT, and of course some arithmetic) and dequantization of 8 blocks (for its coefficient); this means we now have 512 coefficients, so we add a barrier, do 64 horizontal IDCTs (one 8-point IDCT per thread), add a new barrier, do 64 vertical IDCTs, and then finally write out the data. We can then do the next 8 coefficients the same way (we kept the rANS decoding state), and so on. Note how the parallelism changes during the decoding; it's a bit counterintuitive at first, and barriers are not for free, but it avoids saving the coefficients to global memory (which is costly). First, the parallelism is over coefficients, then over horizontal DCT blocks, then over vertical DCT blocks, and then we start all over again. In CPU multithreading, this would be very tricky, and probably not worth it at all, but on the GPU, it gives us tons of parallelism. One problem is that the rANS work is going to be unbalanced within each warp. There's a lot more data (and thus more calculation and loading of compressed data from memory) in the lower-frequency coefficients, which means the other threads in the warp are wasting time doing nothing when they do more work. I tried various schemes to balance it better (like making even larger thread groups to get e.g. more coefficient 0s that could work together, or reordering the threads' coefficients in a zizag), but seemingly it didn't help any. Again, the lack of a profiler here is hampering effective performance investigations. In any case, the performance is reasonably good (my GTX 950 does 1280x720 luma-only in a little under 0.4 ms, which equates to ~1400 fps for full 4:2:2). As a side note, GoPro open-sourced their CineForm HD implementation the other day, and I guess it only goes to show that these kind of things really belong on the GPU; they claim similar performance numbers to what I get on my low-end NVIDIA GPU (923.6 fps for 1080p 4:2:2, which would be roughtly 1800 fps on 720p60), but that's on a 4GHz 8-core Broadwell-E, which is basically taking the most expensive enthusiast desktop CPU you can get your hands on and then overclocking it. Kudos to GoPro for freeing it, though (even under a very useful license), even though FFmpeg already had a working reverse-engineered implementation. :-) Next time, we'll look at the encoder, which is a bit more complicated. After that, we'll do some performance tests and probably wrap up the series. Stay tuned.

Russ Allbery: Review: Provenance

Review: Provenance, by Ann Leckie
Publisher: Orbit
Copyright: September 2017
ISBN: 0-316-38863-7
Format: Kindle
Pages: 448
In a rather desperate attempt to please her mother, Ingray has spent every resource she has on extracting the son of a political enemy from Compassionate Removal (think life imprisonment with really good marketing). The reason: vestiges, a cultural touchstone for Ingray's native planet of Hwae. These are invitation cards, floor tiles, wall panels, or just about anything that can be confirmed to have been physically present at an important or historical moment, or in the presence of a famous figure. The person Ingray is retrieving supposedly pulled off the biggest theft of vestiges in history. If she can locate them, it would be a huge coup for her highly-placed politician mother, and the one time she would be victorious in her forced rivalry with her brother. About the best thing that could be said for this plan is that it's audacious. The first obstacle is the arrival of the Geck on the station for a Conclave for renegotiation of the treaty with the Presger, possibly the most important thing going on in the galaxy at the moment, which strands her there without money for food. The second is that the person she has paid so much to extract from Compassionate Removal says they aren't the person she was looking for at all, and are not particularly interested in going with her to Hwae. Only a bit of creative thinking in the face of a visit from the local authorities, and the unexpected kindness of the captain from whom she booked travel, might get her home with the tatters of her plan intact. But she's clearly far out of her depth. Provenance is set in the same universe as Ancillary Justice and its sequels, but it is not set in the empire of the Radchaai. This is another human world entirely, one with smaller and more provincial concerns. The aftermath of Ancillary Mercy is playing out in the background (so do not, on risk of serious spoilers, read the start of this book without having read the previous trilogy), but this is in no way a sequel. Neither the characters nor the plot are involved in that aftermath. It's a story told at a much smaller scale, about two political families, cut-throat maneuvering, horrible parenting, the inexplicable importance of social artifacts, the weirdness of human/alien relations, and the merits of some very unlikely allies. Provenance is a very different type of story than Ancillary Justice, and Ingray is a very different protagonist. The shape of the plot reminded me of one of Lois McMaster Bujold's Miles Vorkosigan stories: hair-brained ideas, improvisation, and unlikely allies. But Ingray couldn't be more different than Miles. She starts the book overwhelmed, despairing, and not at all manic, and one spends the first part of the story feeling sorry for her and becoming quite certain that everything will go horribly wrong. The heart of this book is the parallel path Leckie takes the reader and the characters along as they discover just what Ingray's true talents and capabilities are. It's a book about being hopelessly bad at things one was pressured towards being good at, while being quietly and subtly good at the skills that let one survive a deeply dysfunctional family. There are lots of books with very active protagonists, and a depressing number of books with passive protagonists pushed around by the plot. There are very few books that pull off the delicate characterization that Leckie manages here: a protagonist who is rather hopeless at taking charge of the plot in the way everyone wants (but doesn't particularly expect) her to, but who charts her own path through the plot in an entirely unexpected way. It's a story that grows on you. The plot rhythm never works in quite the way one expects from other books, but it builds its own logic and its own rhythm, and reached a very emotionally satisfying conclusion. The Radchaai, or at least one Radchaai citizen, do show up eventually, providing a glimmer of outside view at the Ancillary Justice world. Even better, the Geck play a significant role. I adore Leckie's aliens: they're strange and confusing, but in a refreshingly blunt way rather than abusing gnomic utterances and incomprehensible intelligence. And the foot-stomping of the spider bot made me laugh every time. The stakes are a lot lower here than in Ancillary Justice, and Ingray isn't the sort of character who's going to change the world. But that's okay; indeed, one of the points of this book is why and how that's okay. I won't lie: I'd love more Breq, and I hope we eventually get an exploration of the larger consequences of her story. But this is a delightful story that made me happy and has defter character work than most SF being written. Recommended, but read the Ancillary trilogy first. One minor closing complaint, which didn't change my experience of the book but which I can't help quibbling about: I'm completely onboard with the three-gender system that Leckie uses for the Hwae (I wish more SF authors would play with social as well as technological ideas), and I think she wove it deftly into the story, but I wish she hadn't used Spivak pronouns for the third gender. (e/em/eir, for those who aren't familiar.) Any of the other gender-neutral pronouns look better to me and cause fewer problems for my involuntary proofreader. I prefer zie/zir for personal reasons, but sie/hir, zhe/zhim/zher, or even thon or per would read more smoothly. Eir is fine, but em looks like 'em and throws my brain into dialect mode and forces a re-parse, and e just looks like a typo. I know from lots of Usenet discussions of pronouns that I'm not the only one who has that reaction to Spivak. But it's a very minor nit. Rating: 8 out of 10

27 October 2017

Russ Allbery: Review: The Black Gryphon

Review: The Black Gryphon, by Mercedes Lackey & Larry Dixon
Series: Mage Wars #1
Publisher: DAW
Copyright: 1994
Printing: January 1995
ISBN: 0-88677-643-0
Format: Mass market
Pages: 460
The Mage Wars series (or the Gryphon series, which isn't its official title but which is in all of the titles) is part of the sprawling Valdemar mega-series, but it's a prequel to all of the other stories. It's also slightly challenging if you're reading in publication order, since it was published simultaneously with the Mage Storms series. If you're following publication order, in theory you should interleave the two series, but I hate doing that. I'm therefore reading it after Mage Winds and before Mage Storms. We'll see whether that was a good idea when I get to the next series. You could, if you really wanted to, read this series before any other Valdemar book. As a prequel from the deep past of Valdemar's world, it doesn't depend on the other series, and you'll get a rediscovery of lost knowledge feel from later books. The downside is that it's a rather boring introduction, and that order would spoil a lot of the revelatory flow of the other series (particularly Elspeth's adventures in the Mage Winds books). I'm now getting into the Valdemar books that I've only read once. I've been putting off continuing my Valdemar re-read because this series was next and I remember being rather bored with it the first time I read it. But I'm re-reading for the world-building and background as much as for the characters, and this is a huge chunk of world background that fills in the bones underneath Winds of Fate and its sequels. Here's why Dhorisha is a crater, here's why the Pelagiris forests are such a mess, here's where Ma'ar starts, here's the origin of both the gryphons and K'Leshya, and here, finally, we get to see the legendary Urtho on the page. The problem with writing novels set in the epic backstory of your universe is that it's hard to live up to the drama that readers have invented for themselves. A lot of The Black Gryphon is background to events Valdemar readers already know will happen, creating a corresponding lack of surprise. I reached the end of the book and said "yup, that's pretty much what everyone said had happened." Lackey and Dixon do try to do some interesting things here, one of which being the backgrounding of the war. The Black Gryphon starts in the middle of a long-running conflict between Urtho and Ma'ar and doesn't follow the generals or the battles. The protagonists, instead, are a kestra'chern (a type of psychiatrist and spiritual healer who also uses sex, with the expected conflicts of people who incorrectly think of them as prostitutes) and the eventual leader of the gryphons (Skandranon, who is referenced in later books and who provides the title). We get some combat scenes from Skandranon and later another gryphon, but a lot of the book is Amberdrake fighting the effects of the war instead of the details of the war itself. There's a deep and moving story in that idea, and in some of the attached love stories that play out in the army camps. There's also a great story somewhere around Urtho: a brilliant but detached mage who is way out of his depth trying to run an army but smart enough to gather good people around him. He's also a creator of new life, including the gryphons. The Black Gryphon tries to talk about Urtho's paternalism, the weird emotional currents of his relationship with his creations, and the places Urtho keeps things from others for, supposedly, their own good. If this book had looked a bit deeper at the support structure for an army that's trying to be humane, or at the ways in which Urtho strays far too close to being an abusive tyrant through inaction despite having the best of intentions at every step, I think it could have said something significant. Unfortunately, that's not this book. This book is full of relentlessly black and white morality (the flaw of much of the Valdemar series) that bleaches away interesting shades of grey. Urtho is good and wise by authorial fiat, and Ma'ar is the same utterly irredeemable force of evil that he is in other books. The story skitters over Urtho's odd tyrannies, making them all better with the pure power of friendship and good intentions. There just isn't much emotional depth, and while I don't expect that of Lackey in general, this story really needed that depth to work. What we get instead is repetition, as Lackey and Dixon hit the same emotional notes with Amberdrake repeatedly. This is one of those books that makes me wonder if Lackey was trying to write too many novels in a short time than was good for their individual quality. (Collaborations often mean that the lesser-known name is doing all the work, but Dixon is Lackey's husband and the tone of the book is sufficiently Lackey that I don't think that happened here.) It felt padded by Amberdrake turning over the same emotional rocks repeatedly, to largely the same effect. This is, in short, not Lackey's finest effort, although it does have its moments. As always, Lackey is at her best when writing psychological healing narratives. Zhaneel's story is a bit too easy, but the dynamic between Amberdrake and Winterhart is the best part of the book. And The Black Gryphon does tell the reader exactly what led up to the Cataclysm and why. There are no major surprises, but there are some small ones, and it's a nice payoff for the lore-obsessed (like me). This is missable unless you want the full world-building behind Valdemar's past, and it's not the best writing. But if you're heavily invested in the Valdemar universe, it's at least readable and provides an important bit of the history. Followed by The White Gryphon. Rating: 5 out of 10

26 October 2017

Russell Coker: Anarchy in the Office

Some of the best examples I ve seen of anarchy working have been in corporate environments. This doesn t mean that they were perfect or even as good as a theoretical system in which a competent manager controlled everything, but they often worked reasonably well. In a well functioning team members will encourage others to do their share of the work in the absence of management. So when the manager disappears (doesn t visit the team more than once a week and doesn t ask for any meaningful feedback on how things are going) things can still work out. When someone who is capable of doing work isn t working then other people will suggest that they do their share. If resources for work (such as a sufficiently configured PC for IT work) aren t available then they can be found (abandoned PCs get stripped and the parts used to upgrade the PCs that need it most). There was one time where a helpdesk worker who was about to be laid off was assigned to the same office as me (apparently making all the people in his group redundant took some time). So I started teaching him sysadmin skills, assigned work to him, and then recommended that my manager get him transferred to my group. That worked well for everyone. One difficult case is employees who get in the way of work being done, those who are so incompetent that they break enough things to give negative productivity. One time when I was working in Amsterdam I had two colleagues like that, it turned out that the company had no problem with employees viewing porn at work so no-one asked them to stop looking at porn. Having them paid to look at porn 40 hours a week was much better than having them try to do work. With anarchy there s little option to get rid of bad people, so just having them hang out and do no work was the only option. I m not advocating porn at work (it makes for a hostile work environment), but managers at that company did worse things. One company I worked for appeared (from the non-management perspective) to have a management culture of doing no work. During my time there I did two annual reviews in two weeks, and the second was delayed by over 6 months. The manager in question only did the reviews at that time because he was told he couldn t be promoted until he got the backlog of reviews done, so apparently being more than a year behind in annual reviews was no obstacle to being selected for promotion. On one occasion I raised the issue of a colleague who had done no work for over a year (and didn t even have a PC to do work) with that manager, his response was what do you expect me to do ! I expected him to do anything other than blow me off when I reported such a serious problem! But in spite of that strictly work-optional culture enough work was done and the company was a leader in it s field. There has been a lot of research into the supposed benefits of bonuses etc which usually turn out to reduce productivity. Such research is generally ignored presumably because the people who are paid the most are the ones who get to decide whether financial incentives should be offered so they choose the compensation model for the company that benefits themselves. But the fact that teams can be reasonably productive when some people are paid to do nothing and most people have their work allocated by group consensus rather than management plan seems to be a better argument against the typical corporate management. I think it would be interesting to try to run a company with an explicit anarchic management and see how it compares to the accidental anarchy that so many companies have. The idea would be to have minimal management that just does the basic HR tasks (preventing situations of bullying etc), a flat pay rate for everyone (no bonuses, pay rises, etc) and have workers decide how to spend money for training, facilities, etc. Instead of having middle managers you would have representatives elected from each team to represent their group to senior management. PS Australia has some of the strictest libel laws in the world. Comments that identify companies or people are likely to be edited or deleted.
Related posts:
  1. Preferring Not To I ve just read Bartleby the Scrivener which is a short...
  2. Contract Pay Rates In a comment on my post about Bad Project Management...
  3. more about securing an office My post about securing an office received many comments, so...

Russ Allbery: Review: Waypoint Kangaroo

Review: Waypoint Kangaroo, by Curtis C. Chen
Series: Kangaroo #1
Publisher: Thomas Dunne
Copyright: June 2016
ISBN: 1-250-08179-3
Format: Kindle
Pages: 312
Disclaimer: Curtis was a classmate of mine at Stanford and part of the same social circle. That was a surprisingly long time ago. Kangaroo is a spy (and, for this book, you should think James Bond). Agency training, fake identities, lots of gadgets, grumpy yet ridiculously competent support staff... the typical package. But Kangaroo also has a special power, which is the entire reason he ended up in the position he has. He's apparently the only person in the world who can open the pocket: a hole into another dimension, which can function as infinite storage and quite a bit more. Waypoint Kangaroo opens with the tail end of a mission and Kangaroo in action, as an introduction to Kangaroo's first-person narrative voice, job, and the capabilities of the pocket. But the real story starts when Kangaroo is sent on vacation. The office is being audited, Kangaroo hasn't had time off basically ever, and his boss insists on a trip to Mars on the space equivalent of a cruise ship. No work. An expense account. Just relax and have fun. Kangaroo isn't sure he knows how to not work. Or how to avoid boredom when trying hard to not work. It leads to probably ill-advised decisions like falling in love at first glance with the chief engineer, or going on entirely unauthorized spacewalks in the middle of the night. It's very lucky for him that the captain of this commercial cruise ship appears to also work for his agency. And it's good for his inability to stop working that there's a murder on board. For a first novel, this is refreshingly free of a lot of first novel problems. It's lean, well-structured, easy to follow, moves right along, and doesn't feel over-stuffed with exposition or world-building. There's an interplanetary war in the past background, and of course a lot of loving description of the precise mechanics of the pocket and the tricks with momentum and retrieval Kangaroo can do with it, but the book never falls into too much explanation. And the plot is satisfyingly twisty. It's an action story plot, to be clear: don't expect deep puzzles or complex deduction. But there are enough players and hidden motives to keep things interesting. The downside is that I didn't like Kangaroo very much. He's a bit of an ass. Some of this goes with the spy novel territory, and some of it is good (if occasionally grating) characterization. Kangaroo doesn't know how to turn off the part of his brain that makes everything a mission. But his flippant, know-it-all attitude got on my nerves after a book full of first-person narration, and while (full credit to Curtis here) the romance in this book is clearly consensual and stays well away from the creepy romances so common in spy stories, the love-at-first sight bits and some of Kangaroo's awkward reactions provoked more eye-rolling than enjoyment. A lot of this is just personal taste, but that's the peril of books told with first-person narration. The reader has to really like the protagonist to spend a whole book in their head. If that relationship doesn't click, the supporting characters have a harder time salvaging the experience. Waypoint Kangaroo avoids the problem of too many loving descriptions of guns, partly because it's a spy novel and instead has loving descriptions of spy equipment in a future that supports implanted devices. I think there was a smidgen too much of this, but it was within genre conventions and spy stuff is more interesting than guns. But (and I admit that this is probably idiosyncratic), it also had way too many loving descriptions of alcohol and one drunk scene. I don't care to ever read another book with a drunk protagonist (particularly first-person), and I care considerably less about alcohol than I do about spy equipment or guns. That said, I still liked this well enough that I'll probably buy the sequel. (No cliffhangers; Waypoint Kangaroo is a complete story. But this is a character who could easily support a long episodic series.) The pocket is a neat gimmick, the world background is at least mildly interesting, and some of the supporting characters were excellent. (Particularly the security chief and the engineer.) I might even warm to Kangaroo over time if subsequent stories stay more on his creative fast-talking rather than his drinking and awkward romances. I don't think this is quite good enough for me to recommend it, but if you're in the mood for a light and fast-moving first-person Bond-style story with science fiction trappings, it does deliver. Rating: 6 out of 10

25 October 2017

Russ Allbery: Review: Clean Sweep

Review: Clean Sweep, by Ilona Andrews
Series: Innkeeper Chronicles #1
Publisher: NYLA
Copyright: 2013
ISBN: 1-62517-343-1
Format: Kindle
Pages: 228
Dina owns a bed and breakfast in a small town in Texas. As the book opens, her neighbor's dogs are being killed by some beast. As far as Dina is concerned, this should be the problem of the local werewolf, given that this is his territory, and she takes him to task for apparently doing nothing about it. The werewolf doesn't take that well, nor wants to admit to being a werewolf, and reacts by threatening Dina. Given Dina's position and the nature of her bed and breakfast, that turns out to be ill-advised. At this point, you're doubtless thinking urban fantasy, and you're not exactly wrong. You're probably also thinking love interest, and you're not entirely wrong there either. The dead dogs are, of course, an early warning sign of an evil monster who has moved into the area and whose violence may escalate. And if I mention that a vampire shows up later in the story and the werewolf and vampire dislike each other at first sight, you'll probably start rolling your eyes. But this also isn't quite what it looks like on the surface. I'm going to gleefully spoil what you find out about a fifth of the way into the book, since it's what got me to buy this book: neither the werewolves nor the vampires are magical creatures. They're aliens. Werewolves are bio-engineered soldiers; vampires are members of a militaristic order with advanced technology and almost imperceptible circulatory systems. And Dina doesn't truly have a bed and breakfast. She maintains an inn: a refuge for aliens traveling on Earth, part of the secrecy that keeps them out of the eyes of normal humans, and an institution sworn to neutrality in local problems. Dina is straining the last part. The alien creatures who are hunting and killing her neighbors' pets aren't exactly threatening the inn, but she's not willing to stand idly by while her neighbors are threatened. It's a dangerous path, since her inn is struggling already. Failure to prioritize correctly and protect her guests might lower her inn's rating, possibly fatally. She's also without a guide ever since her parents (prominent innkeepers themselves) mysteriously disappeared. But she does have an inn. It may be a weaker one, coaxed out of dormancy and desperately in need of more visitors, but it still has considerable technological resources and other abilities that are indistinguishable from magic. It's also sentient, although more like a large animal than a person, and it knows its innkeeper. This is a light, straightforward sort of book that does not take itself particularly seriously, as you might have guessed. It is very aware of the conventions of urban fantasy and is both following them and intentionally poking fun at them. The authors (Ilona Andrews is a husband and wife writing team) play an impish game of wedging fantasy tropes into a science fiction framework, preserving much of the outward appearance while playing with the explanations. I particularly liked the clannish reworking of vampires into a sort of crusader knight, which works considerably better than it has any right to. Clean Sweep is at its best when the story seems to be going down well-trodden urban fantasy paths and then takes an abrupt right turn into science fiction: Dina going through a dimensional gate to an interstellar marketplace to stock up on weapons, for instance. Also, it has a sentient house. This is one of my favorite story elements ever, provided that the story isn't horror (which is all too often the case with sentient houses, but which is not at all the case here). I found the early parts of this book, during which Sean is insulting Dina and Dina is unimpressed but not doing anything about it, rather tedious. Thankfully, once Dina finally loses her patience and knocks some sense into him it gets a lot better. It never becomes great literature, but sometimes that's a feature. If you're in the mood for some urban fantasy with an adequate, if hand-waved, re-spun science fiction justification and an uncomplicated and loyal sentient house, I can wholeheartedly recommend Clean Sweep. I liked it better than I had expected to. Followed by Sweep in Peace. Rating: 7 out of 10

24 October 2017

Daniel Silverstone: Introducing the car

For many years now, I have been driving a diesel based VW Passat Estate. It has served me very well and been as reliable as I might have hoped given how awful I am with cars. Sadly Gunther was reaching the point where it was going to cost more per year to maintain than the car was worth, and also I've been being more and more irked by not having a car from the future. I spent many months doing spreadsheets, trying to convince myself I could somehow afford a Tesla of some variety. Sadly I never quite managed it. As such I set my sights on the more viable BEVs such as the Nissan Leaf. For a while, nothing I saw was something I wanted. I am quite unusual it seems, in that I don't want a car which is a "Look at me, I'm driving an electric car" fashion statement. I felt like I'd never get something which looked like a normal car, but happened to be a BEV. Then along came the Hyundai Ioniq. Hybrid, Plug-in Hybrid, and BEV all looking basically the same, and not in-your-face-special. I began to covet. Eventually I caved and arranged a test drive of an Ioniq plug-in hybrid because the BEV was basically on 9 month lead. I enjoyed the drive and was instantly very sad because I didn't want a plug-in hybrid, I wanted a BEV. Despondent, I left the dealership and went home. I went online and found a small number of second-hand Ioniq BEVs but as I scrolled through the list, none seemed to be of the right trim level. Then, just as I was ready to give up hope, I saw a new listing, no photo, of the right thing. One snag, it was 200 miles away. No matter, I rang the place, confirmed it was available, and agreed to sleep on the decision. The following morning, I hadn't decided to not buy, so I called them up, put down a deposit to hold the car until I could test drive it, and then began the long and awkward process of working out how I would charge the car given I have no off-street parking so I can't charge at home. (Yeah yeah, you'd think I'd have checked that first, but no I'm just not that sensible). Over the week I convinced myself I could do it, I ordered RFID cards for various schemes, signed up with a number of services, and then, on Friday last week, I drove down to a hotel near the dealership and had a fitful night's sleep. I rocked up to the dealership exactly as they opened for business, shook the hand of the very helpful salesman who had gone through the purchase process with me over the phone during the week, and got to see the car. Instant want coursed through me as I sat in it and decided "Yes, this somehow feels right". I took the car for about a 45 minute test drive just to see how it felt relative to the plug-in hybrid I'd driven the week before and it was like night and day. The BEV felt so much better to drive. I was hooked. Back to the dealership and we began the paperwork. Emptying Gunther of all of the bits and bobs scattered throughout his nooks and crannies took a while and gave me a chance to say goodbye to a car which, on reflection, had actually been a pleasure to own, even when its expensive things went wrong, more than once. But once I'd closed the Passat for the last time, and handed the keys over, it was quite a bittersweet moment as the salesman drove off in what still felt like my car, despite (by this point) it not being so. Sitting in the Ioniq though, I headed off for the 200 mile journey back home. With about 90% charge left after the test drive, I had two stops planned at rapid chargers and I headed toward my first. Unfortunately disaster struck, the rapid (50KW) charger refused to initialise, and I ended up with my car on the slower (7KW) charger to get enough juice into it to drive on to the next rapid charger enabled service station. When I got the message that my maximum charge period (45m) had elapsed, I headed back to the car to discover I couldn't persuade it to unlock from the car. Much hassle later, and an AA man came and together we learned that it takes 2 to tango, one to pull the emergency release in the boot, the other to then unplug the cable. Armed with this knowledge, I headed on my way to a rapid charger I'd found on the map which wasn't run by the same company. Vainly hoping that this would work better, I plugged the car in, set the charger going, and headed into the adjacent shop for a rest break. I went back to the car about 20 minutes later to see the charger wasn't running. Horror of horrors. I imagined maybe some nasty little oik had pressed 'stop' so I started the charger up again, and sat in the car to read my book. After about 3 minutes, the charge stopped. Turns out that charger was slightly iffy and couldn't cope with the charge current and kept emergency-stopping as a result. The lovely lady I spoke to about it directed me to a nearby (12 miles or so, easily done with the charge I had) charger in the grounds of a gorgeous chateau hotel. That one worked perfectly and I filled up. I drove on to my second planned stop and that charge went perfectly too. In fact, every charge since has gone flawlessly. So perhaps my baptism of failed charges has hardened me to the problems with owning a BEV. I've spent the past few days trying different charge points around Manchester enjoying my free charge capability, and trying different names for the car before I finally settled on which is a reasonable Korean boy's name (since the car is Korean I even got to set that as the bluetooth ID) and it's roughly pronounced sock/gin which are two wonderful things in life. I'm currently sat in a pub, eating a burger, enjoying myself while suckles on the teat of "free" electricity to make up for the fact that I've developed a non-trivial habit of leaving Audi drivers in the dust at traffic lights. Further updates may happen as I play with Android Auto and other toys in an attempt to eventually be able to ask the car to please "freeze my buttocks" (a feature it has in the form of air-conditioned seats.)

Reproducible builds folks: Reproducible Builds: Weekly report #130

Here's what happened in the Reproducible Builds effort between Sunday October 15 and Saturday October 21 2017: Past events Upcoming events New York University sessions A three week session will be held at New York University to work on reproducibilty issues in conjunction with the reproducible builds community. Students from the Application Security course will be working for two weeks to work on the reproducible builds effort. Packages reviewed and fixed, and bugs filed The following reproducible builds-related NMUs were accepted: Patches sent upstream: Reviews of unreproducible packages 41 package reviews have been added, 119 have been updated and 54 have been removed in this week, adding to our knowledge about identified issues. 2 issue types were removed as they were fixed: Weekly QA work During our reproducibility testing, FTBFS bugs have been detected and reported by: diffoscope development strip-nondeterminism development Version 0.039-1 was uploaded to unstable by Chris Lamb. It included contributions already covered by posts of the previous weeks, including: reprotest development tests.reproducible-builds.org Website updates Misc. This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Holger Levsen, Santiago Torres & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Russ Allbery: Review: Raven Stratagem

Review: Raven Stratagem, by Yoon Ha Lee
Series: Machineries of Empire #2
Publisher: Solaris
Copyright: 2017
ISBN: 1-78618-046-4
Format: Kindle
Pages: 400
Raven Stratagem is the sequel to Ninefox Gambit and will make very little sense if you've not read the previous book. In fact, I'll add a rare warning, one that I wish I'd had and followed: you need to be deeply familiar with the details of the end of Ninefox Gambit or large chunks of this book will make no sense. I read the previous book earlier this year, but my memory of some of the specifics of the ending had slipped, and I ended up having to skim the ending of the previous book several times. Consider re-reading that bit before starting this book if you share my lack of memory for plot specifics and it's been more than a few months. I unfortunately can't provide a plot summary, since there's almost nothing I can say about the plot that doesn't spoil Ninefox Gambit. It is basically the story that you would expect from the very end of Ninefox Gambit, though, although the way it's carried out is not quite as dramatic as I was expecting. I wanted to like this book a great deal. Ninefox Gambit introduced a beautiful magitech system, but it was otherwise mostly setup and one extended battle. Its ending promised engagement with larger universe politics, and prospects of doing something about the deep unfairness of the current political system. I was hoping this book would contain the payoff of that escalation. It does deliver on that payoff, but something about it didn't quite work for me. The best description I've been able to come up with is that Raven Stratagem skitters. Some of this is an increase in the number of viewpoint characters, which made it harder for me to get into a reading rhythm with any of them. But most of it, I think, is that the characters have so many layers of deception, emotional shielding, weariness, and resignation that it's hard to find the true emotional beats of the story except in retrospect. I kept bouncing off surfaces, so many different and conflicting surfaces. This book is full of people who are not being honest with each other, or sometimes with themselves, and who are pretending to motives they don't really have. As a reader, I wanted to be placed in a privileged position where I could experience the character emotions even when they were lying about them. For good or ill, Raven Stratagem doesn't do that. There was also something about the dramatic structure of the story that didn't work for me. When describing the book to a friend, I said that the main plot climax was off-camera. In skimming the book again for this review, I found that wasn't the case, but it still felt that way. I think that's because, despite some event build-up, the emotional build-up wasn't in place for me, so I wasn't ready as a reader for the climax when it came. The build-up to the climax is partly sacrificed to keep the secrecy of a couple of long-awaited revelations. I very much enjoyed those revelations (one satisfying one was set up with Cheris's behavior at the start of Ninefox Gambit), but I wanted the catharsis of the climax as well. As written, the strongest emotional hit was from a somewhat ancillary climax, and that involved characters who mattered considerably less to me than Cheris. The climax also involves quite a lot of hand-waving. While some of that is expected in magitech, I would have liked to understand the mechanisms of what happened, not just the effects. Lee introduces several new viewpoint characters here, including two very contrasting Kel. I warmed to them by the end of the book, but I liked Cheris as a viewpoint character considerably better than either of them. Both of them spend most of this book in conditions of varying powerlessness; Cheris, despite difficult circumstances, was at least driving the plot. I can kind of see why Lee picked the viewpoint characters he did, but I still feel grumbly about it. I would have loved to have a servitor as a primary viewpoint character in this story. All that said, I'm still glad I read this book. The climax is satisfying, as is the growing respect of the characters and the growing realization of just how the universe is being changed. I wanted more of that on camera rather than being held for dramatic surprise, but I still savored it when it happened. The mechanisms of the Hexarchate, particularly formation instinct, are considerably creepier than Ninefox Gambit reveals, which is saying something, and yet oddly logical in their own magitech way. I liked all the pieces; I just wanted them to have more emotional oomph and momentum. Instead, I felt like I was bringing my own emotion to the story rather than letting the story sweep me away, which meant being more analytical and less engrossed than I prefer to be in a novel. I'm still going to read the third book, though. By the end of Raven Stratagem, Lee has set most of the scenery on fire, and I want to see what sort of world rises from the flames. Rating: 6 out of 10

23 October 2017

Patrick Schoenfeld: Testing javascript in a dockerized rails application with rspec-rails

The other day I wanted to add support for tests of javascript functionality in a (dockerized) rails application using rspec-rails. Since rails 5.1 includes system tests with niceties like automatically taking a screenshot on failed tests, I hoped for a way to benefit from this
features without changing to another test framework. Lucky me only recently the authors of rspec-rails added support for so-called system specs. There is not much documentation so far (but there are a lot of useful information in the corresponding bug report #1838 and a friendly guy named Thomas Walpole (@twalpole) is helpfully answering to questions in that issue. To make things a little bit more complicated: the application in question is usually running in a docker container and thus the tests of the application are also run in a docker container. I didn t want to change this, so here is what it took me to get this running. Overview Let s see what we want to achieve exactly: From a technical point of view, we will have the application under test (AUT) and the tests in one container (let s call it: web) and we will need another container running a javascript-capable browser (let s call it browser). Thus we need the tests to drive a remote running browser (at least when running in a docker environment) which needs to access the application under a different address than usually. Namely an address reachable by the chrome-container, since it will not be reachable via 127.0.0.1 as is (rightfully) assumed by default. If we want Warden authentication stubbing to work (as we do, since our application uses Devise) and transactional fixtures as well (e.g. rails handling database cleanup between tests without database_cleaner gem) we also need to ensure that the application server is being started by the tests and the tests are actually run against that server. Otherwise we might run into problems. Getting the containers ready Assuming you already have a container setup (and are using docker-compose like we do) there is not that much to change on the docker front. Basically you need to add a new service called chrome and point it to an appropriate image and add a link to it in your existing web-container. I ve decided to use standalone-chrome for the browser part, for which there are docker images provided by the selenium project (they also have images for other browsers). Kudos for that. 
...
services:
  chrome:
    image: selenium/standalone-chrome
   
  web:
   
    links:
      - chrome
The link ensures that the chrome instance is available before we run the tests and that the the web-container is able to resolve the name of this container. Unfortunately this is not true for the other way round, so we need some magic in our test code to find out the ip-address of the web-container. More to this later. Other than that, you probably want to configure a volume for you to be able to access the screenshots, which get saved to tmp/screenshots
in the application directory. Preparing the application for running system tests There is a bit more to do on the application side. The steps are roughly:
  1. Add necessary depends / version constraints
  2. Register a driver for the remote chrome
  3. Configure capybara to use the appropriate host for your tests (and your configured driver)
  4. Add actual tests with type: :system and js: true
Let s walk them through. Add necessary depends What we need is the following: The required features are already part of 3.7.0, but this version is the version I used and it contains a bugfix, which may or may not be relevant. One comment about the rails version: for the tests to properly work it s viable to have puma use certain settings. In rails 5.1.4 (the version released, at time of writing this) uses the settings from config/puma.rb which most likely collides with the necessary settings. You can ensure these settings yourself or use rails from branch 5-1-stable which includes this change. I decided for the latter and pinned my Gemfile to the then current commit. Register a driver for the remote chrome To register the required driver, you ll have to add some lines to your rails_helper.rb: 
if ENV['DOCKER']
  selenium_url =
      "http://chrome:4444/wd/hub"
  Capybara.register_driver :selenium_remote do  app 
    Capybara::Selenium::Driver.new(app,
         :url => selenium_url, :browser => :remote, desired_capabilities: :chrome )
  end
end
Note that I added those lines conditionally (since I still want to be able to use a local chrome via chromedriver) if an environment variable DOCKER is set. We defined that environment variable in our Dockerfile and thus you might need to adapt this to your case. Also note that the selenium_url is hard-coded. You could very well take a different approach, e.g. using an externally specified SELENIUM_URL, but ultimately the requirement is that the driver needs to know that the chrome instance is running on host chrome, port 4444 (the containers default). Configure capybara to use the appropriate host and driver The next step is to ensure that javascript-requiring system tests are actually run with the given driver and use the right host. To achieve that we need to add a before-hook to the corresponding tests or we can configure rspec accordingly to always include such a hook by modifying the rspec-configuration in rails_helper.rb like this: 
RSpec.configure do  config 
  ...
  config.before(:each, type: :system, js: true) do
    if ENV['DOCKER']
      driven_by :selenium_remote
      ip = Socket.ip_address_list.detect addr  addr.ipv4_private?  .ip_address
      host! "http://# ip :# Capybara.server_port "
    else
      driven_by :headless_chrome
    end
  end
Note the part with the ip-address: it tries to find an IPv4 private address for the web-container (the container running the tests) to ensure the chrome-container uses this address to access the application. The Capybara.server_port is important here, since it will correspond to the puma instance launched by the tests. That heuristic (first ipv4 private address) works for us at the moment, but it might not work for you. It is basically a workaround to the fact that I couldn t get web resolvable for the chrome container which may be fixable on the docker side, but I was to lazy to further investigate that. If you change it: Just make sure the host! method uses an URI pointing to an address of the web-container that is reachable to the chrome-container. Define tests with type: :system and js: true Last but certainly not least, you need actual tests of the required type and with or without js: true. This can be achieved by creating tests files starting like this: 
RSpec.feature "Foobar", type: :system, js: true do
Since the new rspec-style system tests are based around the feature-specs which used to be around previously, the rest of the tests is exactly like it is described for feature specs. Run the tests To run the tests a commandline like the following should do: docker-compose run web rspec It won t make a big noise about running the tests against chrome, unless something fails. In that case you ll see a message telling you where the screenshot has been placed. Troubleshooting Below I add some hints about problems I ve seen during configuring that: Test failing, screenshot shows login screen In that case puma might be configured wrongly or you are not using transactional fixtures. See the hints above about the rails version to use which also includes some pointers to helpful explanations. Note that rspec-rails by default does not output the puma startup output as it clutters the tests. For debugging purposes it might be helpful to change that by adding the following line to your tests: 
ActionDispatch::SystemTesting::Server.silence_puma = false
Error message: Unable to find chromedriver This indicates that your driver is not configured properly, because the default for system tests is to be driven_by selenium, which tries to spawn an own chrome instance and is suitable for non-dockerized tests. Check if your tests are marked as js: true (if you followed the instructions above) and that you properly added the before-hook to your rspec-configuration. Collisions with VCR If you happen to have tests that make use of the vcr gem you might see it complaining about not knowing what to do with the requests between the driver and the chrome instance. You can fix this, by telling VCR to ignore that requests, by adding a line where you configured VCR: 
VCR.configure do  config 
# required so we don't collide with capybara tests
config.ignore_hosts 'chrome'
...

Russ Allbery: Review: Algorithms to Live By

Review: Algorithms to Live By, by Brian Christian & Tom Griffiths
Publisher: Henry Holt and Company
Copyright: April 2016
ISBN: 1-62779-037-3
Format: Kindle
Pages: 255
Another read for the work book club. This was my favorite to date, apart from the books I recommended myself. One of the foundations of computer science as a field of study is research into algorithms: how do we solve problems efficiently using computer programs? This is a largely mathematical field, but it's often less about ideal or theoretical solutions and more about making the most efficient use of limited resources and arriving at an adequate, if not perfect, answer. Many of these problems are either day-to-day human problems or are closely related to them; after all, the purpose of computer science is to solve practical problems with computers. The question asked by Algorithms to Live By is "can we reverse this?": can we learn lessons from computer science's approach to problems that would help us make day-to-day decisions? There's a lot of interesting material in the eleven chapters of this book, but there's also an amusing theme: humans are already very good at this. Many chapters start with an examination of algorithms and mathematical analysis of problems, dive into a discussion of how we can use those results to make better decisions, then talk about studies of the decisions humans actually make... and discover that humans are already applying ad hoc versions of the best algorithms we've come up with, given the constraints of typical life situations. It tends to undermine the stated goal of the book. Thankfully, it in no way undermines interesting discussion of general classes of problems, how computer science has tackled them, and what we've learned about the mathematical and technical shapes of those problems. There's a bit less self-help utility here than I think the authors had intended, but lots of food for thought. (That said, it's worth considering whether this congruence is less because humans are already good at this and more because our algorithms are designed from human intuition. Maybe our best algorithms just reflect human thinking. In some cases we've checked our solutions against mathematical ideals, but in other cases they're still just our best guesses to date.) This is the sort of a book where a chapter listing is an important part of the review. The areas of algorithms discussed here are optimal stopping, explore/exploit decisions (when to go with the best thing you've found and when to look for something better), sorting, caching, scheduling, Bayes's rule (and prediction in general), overfitting when building models, relaxation (solving an easier problem than your actual problem), randomized algorithms, a collection of networking algorithms, and finally game theory. Each of these has useful insights and thought-provoking discussion of how these sometimes-theoretical concepts map surprisingly well onto daily problems. The book concludes with a discussion of "computational kindness": an encouragement to reduce the required computation and complexity penalty for both yourself and the people you interact with. If you have a computer science background (as I do), many of these will be familiar concepts, and you might be dubious that a popularization would tell you much that's new. Give this book a shot, though; the analogies are less stretched than you might fear, and the authors are both careful and smart about how they apply these principles. This book passes with flying colors a key sanity check: the chapters on topics that I know well or have thought about a lot make few or no obvious errors and say useful and important things. For example, the scheduling chapter, which unsurprisingly is about time management, surpasses more than half of the time management literature by jumping straight to the heart of most time management problems: if you're going to do everything on a list, it rarely matters the order in which you do it, so the hardest scheduling problems are about deciding what not to do rather than deciding order. The point in the book where the authors won my heart completely was in the chapter on Bayes's rule. Much of the chapter is about Bayesian priors, and how one's knowledge of past events is a vital part of analysis of future probabilities. The authors then discuss the (in)famous marshmallow experiment, in which children are given one marshmallow and told that if they refrain from eating it until the researcher returns, they'll get two marshmallows. Refraining from eating the marshmallow (delayed gratification, in the psychological literature) was found to be associated with better life outcomes years down the road. This experiment has been used and abused for years for all sorts of propaganda about how trading immediate pleasure for future gains leads to a successful life, and how failure in life is because of inability to delay gratification. More evil analyses have (of course) tied that capability to ethnicity, with predictably racist results. I have kind of a thing about the marshmallow experiment. It's a topic that reliably sends me off into angry rants. Algorithms to Live By is the only book I have ever read to mention the marshmallow experiment and then apply the analysis that I find far more convincing. This is not a test of innate capability in the children; it's a test of their Bayesian priors. When does it make perfect sense to eat the marshmallow immediately instead of waiting for a reward? When their past experience tells them that adults are unreliable, can't be trusted, disappear for unpredictable lengths of time, and lie. And, even better, the authors supported this analysis with both a follow-up study I hadn't heard of before and with the observation that some children would wait for some time and then "give in." This makes perfect sense if they were subconsciously using a Bayesian model with poor priors. This is a great book. It may try a bit too hard in places (applicability of the math of optimal stopping to everyday life is more contingent and strained than I think the authors want to admit), and some of this will be familiar if you've studied algorithms. But the writing is clear, succinct, and very well-edited. No part of the book outlives its welcome; the discussion moves right along. If you find yourself going "I know all this already," you'll still probably encounter a new concept or neat explanation in a few more pages. And sometimes the authors make connections that never would have occurred to me but feel right in retrospect, such as relating exponential backoff in networking protocols to choosing punishments in the criminal justice system. Or the realization that our modern communication world is not constantly connected, it's constantly buffered, and many of us are suffering from the characteristic signs of buffer bloat. I don't think you have to be a CS major, or know much about math, to read this book. There is a lot of mathematical details in the end notes if you want to dive in, but the main text is almost always readable and clear, at least so far as I could tell (as someone who was a CS major and has taken a lot of math, so a grain of salt may be indicated). And it still has a lot to offer even if you've studied algorithms for years. The more I read of this book, the more I liked it. Definitely recommended if you like reading this sort of analysis of life. Rating: 9 out of 10

Next.

Previous.