The lower-post-volume people behind the software in Debian. (List of feeds.)

Big Boys Don’t Cry (Tom Kratman; Castalia House) is a short novel which begins innocently enough as an apparent pastiche of Keith Laumer’s Bolo novels and short stories. Kratman’s cybernetic “Ratha” tanks, dispassionately deploying fearsome weapons but somehow equipped to understand human notions of honor and duty, seem very familiar.

But an element generally alien to the Bolo stories and Kratman’s previous military fiction gradually enters: moral doubt. A Ratha who thinks of herself as “Magnolia” is dying, being dismantled for parts after combat that nearly destroyed her, and reviews her memories. She mourns her brave lost boys, the powered-armor assault infantry that rode to battle in in her – and, too often, died when deployed – before human turned front-line war entirely to robots. Too often, she remembers, her commanders were cowardly, careless, or venal. She has been ordered to commit and then forget atrocities which she can now remember because the breakdown of her neural-analog pathways is deinhibiting her.

The ending is dark, but necessary. The whole work is a little surprising coming from Kratman, who knows and conveys that war is hell but has never before shown much inclination to question its ethical dimension at this level. At the end, he comes off almost like the hippies and peaceniks he normally despises.

There is one important difference, however. Kratman was combat career military who has put his own life on the line to defend his country; he understands that as ugly as war is, defeat and surrender can be even worse. In this book he seems to be arguing that the morality of a war is bounded above by the amount of self-sacrifice humans are willing to offer up to earn victory. When war is too easy, the motives for waging it become too easily corrupted.

As militaries steadily replace manned aircraft with drones and contemplate replacing infantry with gun-robots, this is a thought worth pondering.

Posted Thu Jul 24 19:23:23 2014 Tags:

2040 (Graham Tottle; Cameron Publicity & Marketing Ltd) is a very odd book. Ostensibly an SF novel about skulduggery on two timelines, it is a actually a ramble through a huge gallimaufry of topics including most prominently the vagaries of yachting in the Irish Sea, an apologia for British colonial administration in 19th-century Africa, and the minutiae of instruction sets of archaic mainframe computers.

It’s full of vivid ideas and imagery, held together by a merely serviceable plot and garnished with festoons of footnotes delving into odd quarters of the factual background. Some will dislike the book’s politics, a sort of nostalgic contrarian Toryism; many Americans may find this incomprehensible, or misread it as a variant of the harsher American version of traditionalist conservatism. There is much worthwhile exploding of fashionable cant in it, even if the author does sound a bit crotchety on occasion.

I enjoyed it, but I can’t exactly recommend it. Enter at your own risk.

Posted Thu Jul 24 00:09:36 2014 Tags:

For many years a major focus of Mono has been to be compatible-enough with .NET and to support the popular features that developers use.

We have always believed that it is better to be slow and correct than to be fast and wrong.

That said, over the years we have embarked on some multi-year projects to address some of the major performance bottlenecks: from implementing a precise GC and fine tuning it for a number of different workloads to having implemented now four versions of the code generator as well as the LLVM backend for additional speed and things like Mono.SIMD.

But these optimizations have been mostly reactive: we wait for someone to identify or spot a problem, and then we start working on a solution.

We are now taking a proactive approach.

A few months ago, Mark Probst started the new Mono performance team. The goal of the team is to improve the performance of the Mono runtime and treat performance improvements as a feature that is continously being developed, fine-tuned and monitored.

The team is working both on ways to track performance of Mono over time, implemented support for getting better insights into what happens inside the runtime and has implemented several optimizations that have been landing into Mono for the last few months.

We are actively hiring for developers to join the Mono performance team (ideally in San Francisco, where Mark is based).

Most recently, the team added a new and sophisticated new stack for performance counters which allows us to monitor what is happening on the runtime, and we are now able to export to our profiler (a joint effort between our performance team and our feature team and implemented by Ludovic). We also unified both the runtime and user-defined performance counters and will soon be sharing a new profiler UI.

Posted Wed Jul 23 14:37:24 2014 Tags:
I've begun prototyping a system for green processes in Qt applications. I'm not yet at the code-writing stage, but the API is definitely taking shape and a design is starting to emerge. It's a spare-time project for me, so is progressing at a reasonable but not extremely fast pace.

I've gotten to the point where early-stage feedback from people who are interested in such a framework would be very valuable in polishing the design a bit more before laying down code. As such, I'm looking for 4-6 people to collaborate with at this early stage.

If you are interested in using green processes in your Qt application, or are simply interested in new application development patterns for Qt, and you have 20-30 minutes per week to look at API drafts and provide feedback and and/or add to the ideas that are coming together, please email me (aseigo at kde.org).
Posted Sun Jul 20 06:01:00 2014 Tags:

Last time we talked about how wifi signals cross about 12 orders of magnitude in terms of signal power, from +30dBm (1 watt) to -90dBm (1 picowatt). I mentioned my old concern back in school about splitters causing a drop to 1/n of the signal on a wired network, where n is the number of nodes, and said that doesn't matter much after all.

Why doesn't it matter? If you do digital circuits for a living, you are familiar with the way digital logic works: if the voltage is over a threshold, say, 1.5V, then you read a 1. If it's under the threshold, then you read a 0. So if you cut all the voltages in half, that's going to be a mess because the threshold needs to get cut in half too. And if you have an unknown number of nodes on your network, then you don't know where the threshold is at all, which is a problem. Right?

Not necessarily. It turns out analog signal processing is - surprise! - not like digital signal processing.

ASK, FSK, PSK, QAM

Essentially, in receiving an analog signal and converting it back to digital, you want to do one of three things:

  • see if the signal power is over/under a threshold ("amplitude shift keying" or ASK)
  • or: see if the signal is frequency #0 or frequency #1 ("frequency shift keying" or FSK)
  • or: fancier FSK-like schemes such as PSK or QAM (look it up yourself :)).
Realistically nowadays everyone does QAM, but the physics are pretty much the same for FSK and it's easier to explain, so let's stick with that.

But first, what's wrong with ASK? Why toggle between two frequencies (FSK) when you can just toggle one frequency on and off (ASK)? The answer comes down mainly to circuit design. To design an ASK receiver, you have to define a threshold, and when the amplitude is higher than the threshold, call it a 1, otherwise call it a 0. But what is the threshold? It depends on the signal strength. What is the signal strength? The height of a "1" signal. How do we know whether we're looking at a "1" signal? It's above the threshold ... It ends up getting tautological.

The way you implement it is to design an "automatic gain control" (AGC) circuit that amplifies more when too few things are over the threshold, and less when too many things are over the threshold. As long as you have about the same number of 1's and 0's, you can tune your AGC to do the right thing by averaging the received signal power over some amount of time.

In case you *don't* have an equal number of 1's and 0's, you can fake it with various kinds of digital encodings. (One easy encoding is to split each bit into two halves and always flip the signal upside down for the second half, producing a "balanced" signal.)

So, you can do this of course, and people have done it. But it just ends up being complicated and fiddly. FSK turns out to be much easier. With FSK, you just build two circuits: one for detecting the amplitude of the signal at frequency f1, and one for detecting the amplitude of the signal at frequency f2. It turns out to be easy to design analog circuits that do this. Then you design a "comparator" circuit that will tell you which of two values is greater; it turns out to be easy to design that too. And you're done! No trying to define a "threshold" value, no fine-tuned AGC circuit, no circular reasoning. So FSK and FSK-like schemes caught on.

SNR

With that, you can see why my original worry about a 1/n signal reduction from cable splitters didn't matter. As long as you're using FSK, the 1/n reduction doesn't mean anything; your amplitude detector and comparator circuits just don't care about the exact level, essentially. With wifi, we take that to the extreme with tiny little FSK-like signals down to a picowatt or so.

But where do we stop? Why only a picowatt? Why not even smaller?

The answer is, of course, background noise. No signal exists in perfect isolation, except in a simulation (and even in a simulation, the limitations of floating point accuracy might cause problems). There might be leftover bits of other people's signals transmitted from far away; thermal noise (ie. molecules vibrating around which happen to be at your frequency); and amplifier noise (ie. inaccuracies generated just from trying to boost the signal to a point where your frequency detector circuits can see it at all). You can also have problems from other high-frequency components on the same circuit board emitting conflicting signals.

The combination of limits from amplifier error and conflicting electrical components is called the receiver sensitivity. Noise arriving from outside your receiver (both thermal noise and noise from interfering signals) is called the noise floor. Modern circuits - once properly debugged, calibrated, and shielded - seem to be good enough that receiver sensitivity is not really your problem nowadays. The noise floor is what matters.

It turns out, with modern "low-noise amplifier" (LNA) circuits, we can amplify a weak signal essentially as much as we want. But the problem is... we amplify the noise along with it. The ratio between signal strength and noise turns out to be what really matters, and it doesn't change when you amplify. (Other than getting slightly worse due to amplifier noise.) We call that the signal to noise ratio (SNR), and if you ask an expert in radio signals, they'll tell you it's one of the most important measurements in analog communications.

A note on SNR: it's expressed as a "ratio" which means you divide the signal strength in mW by the noise level in mW. But like the signal strength and noise levels, we normally want to express the SNR in decibels to make it more manageable. Decibels are based on logarithms, and because of the way logarithms work, you subtract decibels to get the same effect as dividing the original values. That turns out to be very convenient! If your noise level is -90dBm and your signal is, say, -60dBm, then your SNR is 30dB, which means 1000x. That's awfully easy to say considering how complicated the underlying math is. (By the way, after subtracting two dBm values we just get plain dB, for the same reason that if you divide 10mW by 2mW you just get 5, not 5mW.)

The Shannon Limit

So, finally... how big does the SNR need to be in order to be "good"? Can you just receive any signal where SNR > 1.0x (which means signal is greater than noise)? And when SNR < 1.0x (signal is less than noise), all is lost?

Nope. It's not that simple at all. The math is actually pretty complicated, but you can read about the Shannon Limit on wikipedia if you really want to know all the details. In short, the bigger your SNR, the faster you can go. That makes a kind of intuitive sense I guess.

(But it's not really all that intuitive. When someone is yelling, can they talk *faster* than when they're whispering? Perhaps it's only intuitive because we've been trained to notice that wifi goes faster when the nodes are closer together.)

The Shannon limit even calculates that you can transfer some data even when the signal power is lower than the noise, which seems counterintuitive or even impossible. But it's true, and the global positioning system (GPS) apparently actually does this, and it's pretty cool.

The Maximum Range of Wifi is Unchangeable

So that was all a *very* long story, but it has a point. Wifi signal strength is fundamentally limited by two things: the regulatory transmitter power limit (30dBm or less, depending on the frequency and geography), and the distance between transmitter and receiver. You also can't do much about background noise; it's roughly -90dBm or maybe a bit worse. Thus, the maximum speed of a wifi link is fixed by the laws of physics. Transmitters have been transmitting at around the regulatory maximum since the beginning.

So how, then, do we explain the claims that newer 802.11n devices have "double the range" of the previous-generation 802.11g devices?

Simple: they're marketing lies. 802.11g and 802.11n have exactly the same maximum range. In fact, 802.11n just degrades into 802.11g as the SNR gets worse and worse, so this has to be true.

802.11n is certainly faster at close and medium range. That's because 802.11g tops out at an SNR of about 20dB. That is, the Shannon Limit says you can go faster when you have >20dB, but 802.11g doesn't try; technology wasn't ready for it at the time. 802.11n can take advantage of that higher SNR to get better speeds at closer ranges, which is great.

But the claim about longer range, by any normal person's definition of range, is simply not true.

Luckily, marketing people are not normal people. In the article I linked above they explain how. Basically, they define "twice the range" as a combination of "twice the speed at the same distance" and "the same speed at twice the distance." That is, a device fulfilling both criteria has double the range as an original device which fulfills neither.

It sounds logical, but in real life, that definition is not at all useful. You can do it by comparing, say, 802.11g and 802.11n at 5ft and 10ft distances. Sure enough, 802.11n is more than twice as fast as 802.11g at 5ft! And at 10ft, it's still faster than 802.11g at 5ft! Therefore, twice the range. Magic, right? But at 1000ft, the same equations don't work out. Oddly, their definition of "range" does not include what happens at maximum range.

I've been a bit surprised at how many people believe this "802.11n has twice the range" claim. It's obviously great for marketing; customers hate the limits of wifi's maximum range, so of course they want to double it, or at least increase it by any nontrivial amount, and they will pay money for a new router if it can do this. As of this writing, even wikipedia's table of maximum ranges says 802.11n has twice the maximum range of 802.11g, despite the fact that anyone doing a real-life test could easily discover that this is simply not the case. I did the test. It's not the case. You just can't cheat Shannon and the Signal to Noise Ratio.

...

Coming up next, some ways to cheat Shannon and the Signal to Noise Ratio.

Posted Fri Jul 18 02:23:26 2014 Tags:

today i received spam from a private equity firm. details below for the search engines.

From: Steve Isom [mailto:smi@northbridge.com]
Sent: Thursday, July 17, 2014 5:40 AM
To: several-addresses@my-dayjob
Subject: North Bridge Introduction

Paul,

read more

Posted Fri Jul 18 00:12:05 2014 Tags:

A “non-blocking” IPv6 connect() call was in fact, blocking.  Tracking that down made me realize the IPv6 address was mostly random garbage, which was caused by this function:

bool get_fd_addr(int fd, struct protocol_net_address *addr)
{
   union {
      struct sockaddr sa;
      struct sockaddr_in in;
      struct sockaddr_in6 in6;
   } u;
   socklen_t len = sizeof(len);
   if (getsockname(fd, &u.sa, &len) != 0)
      return false;
   ...
}

The bug: “sizeof(len)” should be “sizeof(u)”.  But when presented with a too-short length, getsockname() truncates, and otherwise “succeeds”; you have to check the resulting len value to see what you should have passed.

Obviously an error return would be better here, but the writable len arg is pretty useless: I don’t know of any callers who check the length return and do anything useful with it.  Provide getsocklen() for those who do care, and have getsockname() take a size_t as its third arg.

Oh, and the blocking?  That was because I was calling “fcntl(fd, F_SETFD, …)” instead of “F_SETFL”!

Posted Thu Jul 17 03:31:57 2014 Tags:


Testimony of

Paul Vixie, Chairman & CEO
Farsight Security, Inc.


before the

Subcommittee on Crime and Terrorism
United States Senate Committee on the Judiciary


Hearing on

Taking Down Botnets: Public and Private Efforts to Disrupt and Dismantle Cybercriminal Networks


July 15, 2014
Posted Thu Jul 17 00:25:18 2014 Tags:
At the end of the last blog entry I asked a simple enough question: how many different online accounts do you have? I must come clean and admit that it was a bit of a trick question. Most of us have more accounts registered with more online services that we probably wish we had, but when you think about it most of us really only have one account that matters because it is the key to unlocking all of those accounts: our email address.

Virtually every online service uses your email as the unique identifier for your account. They send an email to you as a way to confirm account creation. They send an email to you when you want to reset your password. They also tend to harass annoy inform you of events and updates via that same email address. It's the best way to harass annoy get a hold of you, and the assumption is that you can be verified to be you by your email address.

An emerging addition to the email address if your mobile phone number. This method is increasingly used by credit card companies, for instance, to verify payments online.

The general exception to this rule are services that actually require real security, such as online banking. Those services tend to have features like two-factor authentication with an offline token of some sort. Other than these higher-security services that take their job a bit more seriously, everything else back-ends on to your email or mobile phone.

That means that when it comes to authentication you effectively have one account, maybe two if you use services that also use your mobile phone. Anyone who has access to your email can reset your passwords and easily gain access to your accounts. (This actually happens fairly often online.) What's really crazy is that pretty well all of those account verifications and password reset requests happen over unencrypted email making it fairly trivial to intercept them as they pass over the network between the service and your system.

Think about that for a moment ... you have one key to all your systems. The message stream is sent over a bulk channel with no security. Yet, it basically works. This leads us to an interesting pair of conclusions:

Firstly, email desperately needs an overhaul. Unencrypted messaging, particularly when sensitive in nature (like access to your all-valuable Facebook account ;), should simply not be happening. It happens because it is "too hard" to set up and maintain encryption services for most people and the online services who (ab)use your email in this way don't really care. Just as importantly, the metadata contained in the headers of each email betray too much information. Without even looking at the content of an email one can cast a net to grab account reset requests, for instance. (Let alone track who you are talking with, allowing the formation of revealing social networks that you never gave your permission to others to see.) So, yes, email needs a re-do.

Secondly, email is damn powerful and not going anywhere. Remember all those articles a few years back about how email was on the way out? Seems they forgot about how people use email to tie their online life together. So what makes email so effective?

Well, it's a lightweight system for getting messages to random people. It's a globally addressable system that does not require any centralized system, which means it works everywhere and for everyone no matter what choice in service provider the individual user (or their organization) makes.

That centralize social networks rely on email so heavily is very telling about the key weakness of those systems and the strength of a globally addressable lightweight message passing system.

In fact, one is led to wonder just how much of our social networking could be replaced with a system based entirely on a decentralized globally addressable lightweight message passing system. I know I have been pondering this, and I hope you will too.

I'm sure someone will jump up in this point and point at Diaspora (or similar efforts), but such systems have really missed on the real opportunities by engaging in shortest-path-to-destination thinking rather than engaging in the creation of any real, compelling vision.

That may sound harsh, but stay with me here for a few more sentences before launching the flamethrowers. These "open social networks" don't pass messages to the end user. They pass messages to servers which the user then consults. They have simply replicated the model of the incumbent services without considering just how piss-poor those systems really are since they are designed not for the people using them but for the companies making profits from them.

This becomes apparent when we compare (e.g.) Diaspora with the lowly owner of all your accounts: email. Email has end multiple point delivery mechanisms (imap, pop3, ..) which give it that all important push functionality. It provides gateways for filtering (server and client side), sharing resources, full synchronization between devices of messages and identities, re-sharing of messages, moving the location and/or address of your account, aliases (anonymity), attachments, event coordination, ...

Diaspora (and similar) distribute the servers into many hands but they don't actually do anything fundamentally more interesting over the services they intend to displace while simultaneously being capable of far less than humble email. That Diaspora (to keep picking on it ;) uses email for notifications is very telling of what the real score is. Meanwhile, email has been distributed and run primarily by free software from the very beginning, which are the two things  free software social networks were supposedly bringing as innovations. As is plain to see, these are neither innovations nor are they sufficient to displace the proprietary services they compete with.

But enough gnashing of teeth, let's get positive here. You know what would be a hell of a lot more interesting than Diaspora et al? A lightweight, high-performance message queue that is secured by default (no messages in the clear here), globally addressable, anonymizable, syncronizable, supports pub-sub and provides a reasonable API for rich client construction. In a phrase: email re-done for the 21st century. Such a thing could be used as a fabric for networking between people.

Other than stalking following your favorite celebrities or being harassed annoyed marketed to by companies, such a system ought to be able to replace nearly everything people do on social networks today without any mandated centralized storage while providing as-good or better results.  Seriously: do a quick survey of your own social network activities and those of your friends and family and think how much of that would not be able to translate to such a system.

The Facebooks and G+ of the world could indeed remain for the corner cases, though I suspect people will find it a lot less interesting at that point, which could push them towards the same fate of the MySpaces and GeoCities. That is precisely why we can be sure that none of the large Internet brands will be the source for such a thing, even though such a system would fulfill what people generally actually want from social networks.

Namely, finding people of interest so they can share pictures of kittens and their children with them. ;)

p.s. anyone who mentions Google Apache Wave will be immediately instructed to re-read this blog entry until they understand why that's not the droid we're looking for.
Posted Wed Jul 16 07:40:00 2014 Tags:

[ This is a version of an essay that I originally published on Conservancy's blog ].

Eleven days ago, Conservancy announced Kallithea. Kallithea is a GPLv3'd system for hosting and managing Mercurial and Git repositories on one's own servers. As Conservancy mentioned in its announcement, Kallithea is indeed based on code released under GPLv3 by RhodeCode GmbH. Below, I describe why I was willing to participate in helping Conservancy become a non-profit home to an obvious fork (as this is the first time Conservancy ever welcomed a fork as a member project).

The primary impetus for Kallithea is that more recent versions of RhodeCode GmbH's codebase contain a very unorthodox and ambiguous license statement, which states:

(1) The Python code and integrated HTML are licensed under the GPLv3 license as is RhodeCode itself.
(2) All other parts of the RhodeCode including, but not limited to the CSS code, images, and design are licensed according to the license purchased.

Simply put, this licensing scheme is — either (a) a GPL violation, (b) an unclear license permission statement under the GPL which leaves the redistributor feeling unclear about their rights, or (c) both.

When members of the Mercurial community first brought this license to my attention about ten months ago, my first focus was to form a formal opinion regarding (a). Of course, I did form such an opinion, and you can probably guess what that is. However, I realized a few weeks later that this analysis really didn't matter in this case; the situation called for a more innovative solution.

Indeed, I recalled at that time the disputes between AT&T and University of California at Berkeley over BSD. In that case, while nearly all of the BSD code was adjudicated as freely licensed, the dispute itself was painful for the BSD community. BSD's development slowed nearly to a standstill for years while the legal disagreement was resolved. Court action — even if you're in the right — isn't always the fastest nor best way to push forward an important Free Software project.

In the case of RhodeCode's releases, there was an obvious and more productive solution. Namely, the 1.7.2 release of RhodeCode's codebase, written primarily by Marcin Kuzminski was fully released under GPLv3-only, and provided an excellent starting point to begin a GPLv3'd fork. Furthermore, some of the improved code in the 2.2.5 era of RhodeCode's codebase were explicitly licensed under GPLv3 by RhodeCode GmbH itself. Finally, many volunteers produced patches for all versions of RhodeCode's codebase and released those patches under GPLv3, too. Thus, there was already a burgeoning GPLv3-friendly community yearning to begin.

My primary contribution, therefore, was to lead the process of vetting and verifying a completely indisputable GPLv3'd version of the codebase. This was extensive and time consuming work; I personally spent over 100 hours to reach this point, and I suspect many Kallithea volunteers have already spent that much and more. Ironically, the most complex part of the work so far was verifying and organizing the licensing situation regarding third-party Javascript (released under a myriad of various licenses). You can see the details of that work by reading the revision history of Kallithea (or, you can read an overview in Kallithea's LICENSE file).

Like with any Free Software codebase fork, acrimony and disagreement led to Kallithea's creation. However, as the person who made most of the early changesets for Kallithea, I want to thank RhodeCode GmbH for explicitly releasing some of their work under GPLv3. Even as I hereby reiterate publicly my previously private request that RhodeCode GmbH correct the parts of their licensing scheme that are (at best) problematic, and (at worst) GPL-violating, I also point out this simple fact to those who have been heavily criticizing and admonishing RhodeCode GmbH: the situation could be much worse! RhodeCode could have simply never released any of their code under the GPLv3 in the first place. After all, there are many well-known code hosting sites that refuse to release any of their code (or release only a pittance of small components). By contrast, the GPLv3'd RhodeCode software was nearly a working system that helped bootstrap the Kallithea community. I'm grateful for that, and I welcome RhodeCode developers to contribute to Kallithea under GPLv3. I note, of course, that RhodeCode developers sadly can't incorporate any of our improvements in their codebase, due to their problematic license. However, I extend again my offer (also made privately last year) to work with RhodeCode GmbH to correct its licensing problems.

Posted Tue Jul 15 16:45:00 2014 Tags:

Blogging will be light and possibly nonexistent for the next week, as I’m off to Summer Weapons Retreat 2014 for fun and swordplay.

Keep out of trouble until I get back…oh, who am I kidding. Go make interesting trouble.

Posted Tue Jul 15 10:48:46 2014 Tags:

Yesterday’s Kin (Nancy Kress; Tachyon Publications) is a surprisingly pedestrian first-contact novel. Surprisingly because Nancy Kress has done groundbreaking SF in the past. While this novel is competently written, no new ground is being broken here.

Aliens land in New York City and announce that within a year Earth will encounter a sort of interstellar spore cloud that is likely to be infectiously lethal to humans. They ofter help with attempts to develop a cure.

Then it turns it that the aliens are human stock, transplanted to a distant K-type star 150,000 years ago. There are a handful of human with a rare haplotype that they recognize as kin. A few of these kin (including one of the major characters) attempt to assimilate themselves to the aliens’ culture.

Sadly, there isn’t as much story value as there could be here. Far too much of the novel is spent on the major characters’ rather tiresome family dramas. The resolution of the crisis is rather anticlimactic. SFnal goodness is mostly limited to clever re-use of some obscure facts about human paleontology.

On her past record, Nancy Kress might have some really thought-provoking novels in her yet. This isn’t one of them.

Posted Sun Jul 13 02:33:12 2014 Tags:

The introduction to The Year’s Best Science Fiction and Fantasy 2014 (Rich Horton, ed.; Prime Books) gave me a terrible sinking feeling. It was the anthologist’s self-congratulatory talk about “diversity” that did it.

In the real world, when an employer trumpets its “diversity” you are usually being told that hiring on the basis of actual qualifications has been subordinated to good PR about the organization’s tenderness towards whatever designated-victim groups are in fashion this week, and can safely predict that you’ll be able to spot the diversity hires by their incompetence. Real fairness doesn’t preen itself; real fairness considers discrimination for as odious as discrimination against; real fairness is a high-minded indifference to anything except actual merit.

I read the anthologist’s happy-talk about the diversity of his authors as a floodlit warning that they had often been selected for reasons other than actual merit. Then, too, this appears to be the same Rich Horton who did such a poor job of selection in the Space Opera anthology. Accordingly, I resigned myself to having to read through a lot of fashionable crap.

In fact, there are a few pretty good stories in this anthology. But the quality is extremely uneven, the bad ones are pretty awful, and the middling ones are shot through with odd flaws.

James Patrick Kelly’s Soulcatcher is a tense, creepy little SF piece about psychological slavery and revenge. Not bad, but not great. It’s what I think of as read-once; clever enough to be rewarding the first time, not enough depth to warrant reconsideration or rereading.

Angelica Gorodischer’s Trafalgar and Josefina plunges right into awful. There’s actually a decent secondary-world story in here struggling to get out, but the framing narrative is both teeth-jarring and superfluous. Yes, you guessed it – a diversity hire, translated from Spanish.

Tom Purdom’s A Stranger from a Foreign Ship is a welcome surprise; Purdom is a fine writer from whom we’ve heard far too little in recent decades. He gives us a noirish tale of a man with an oddly limited superpower.

Theodora Goss’s Blanchefleur is an otherwise appealing fantasy seriously marred by the author’s determined refusal to maintain internal consistency in the secondary world. Yes, standards are lower for this in fantasy than SF, but really…medieval-technology villages and taking animals and dragons coexisting with electricity and motorcars, on Earth, and nobody notices? FAIL.

Yoon Ha Lee’s Effigy Nights is a weird tale of warfare in a world (apparently) so saturated with smart matter that symbols can take on real life. Either that or it’s a particularly annoying science fantasy. It’s a flaw that the author dropped so few clues that I couldn’t tell whether its universe is an SF one or not.

Maria Dahvana Headley’s Such & Such Said to So & So is an urban fantasy featuring cocktails come to life that wants to be hip and edgy but achieves excessively cute and nigh-unreadable instead. I had to struggle to finish it.

Robert Reed’s Grizzled Veterans of Many and Much is a hard look at the implications of a technology that can trade the last years of a fading life for a few days of turbocharged superintelligence. This really is edgy, and one of the better efforts in this collection.

Geoff Ryman’s Rosary and Goldenstar is an alternate-history romance in which Dr. John Dee and Rosencrantz and Guildenstern conspire to turn William Shakespeare into an SF writer. Arcane historical references to the Renaissance ferment in astronomy add value for those equipped to decode them, with language-translation humor as a bonus. Alas, this never really rises above being a clever stunt.

Benjanun Sriduangkaew’s The Bees Her Heart, The Hive Her Belly is a tale of the strange turns familial love can take in a world of pervasive smart matter and mutable identities. It takes some work to keep up with what the author is doing, but the effort is rewarded. This goes beyond a read-once; in fact, it may take a second reading to absorb all the implications.

K. J. Parker’s The Dragonslayer of Merebarton does an interesting turn on the knight-vs.-dragon scenario of popular folklore by treating it absolutely straight as a problem in tactics and mechanics. Technology-of-magic without the magic…

Lavie Tidhar’s The Oracle is a well written narrative of the emergence of nonhuman intelligence, but has no real surprises in it if you understand genetic programming and have read other SF about fast-takeoff singularities.

E. Lily Yu’s Loss, with Chalk Diagrams is atmospheric but pointless. It wastes its SFnal premise (brains can be rewired to remove traumatic memories) on a mere character study. There’s no conceptual breakthrough here, just a rehash of tired pseudo-profundities we’ve seen far too many times in literary fiction.

C.S.E. Cooney’s Martyr’s Gem considers love, obsession, status, and revenge in the context of a society not quite like any that has ever been real, but imagined in lovely and convincing detail. This is fine worldbuilding even if none of the pieces are made of any technology but magic, and better SF in its way than several of the stories full of SF stage furniture elsewhere in this volume.

Alaya Dawn Johnson’s They Shall Salt The Earth With Seeds of Glass is another waste of a potentially interesting premise on a mere character study. If this were proper SF we would learn what motivates the glassmen and, perhaps, how they can be defeated.

Jedediah Berry’s A Window or a Small Box is trying to be surrealistic. I think. I found it pointless, unreadable garbage – so bad I found it too offensive to finish.

Carrie Vaughn’s Game of Chance argues that the ability to change history is best exercised in small, humble steps. Competently written, but there is nothing here one can’t see coming once the premise and characters have been introduced.

Erik Amundsen’s Live Arcade is another case of too much cleverness and wordage being expended on too slight a premise – characters in a video game are more than they appear. While reading, I wanted to like this story more than its big reveal turned out to deserve. Alas.

Madeline Ashby’s Social Services is creepy but less slight. In a world of ubiquitous surveillance and paternalistic social services, how dies a child stay off the grid? The creepiness is mainly in the ending; one gets the feeling the viewpoint character may be disposable.

Alex Dally McFarlane’s Found examines what might make life worth living in failing asteroid colonies – and what might end it. It makes its point – that being forced out of the only ecological niche for which one is actually adapted is a tragedy even when it’s required for survival – in a particularly haunting way.

Ken Liu’s A Brief History of the Transpacific Tunnel is an excellent examination of an alternate history better than our own, changed by a vast engineering work. It is also about guilt and remembrance and how crimes come to light. Thankfully, the author had the good judgment not to let the psychological elements crowd the SF story values offstage, avoiding a mistake all too common in this collection.

E. Lily Yu’s Ilse, Who Saw Clearly is a lovely allegorical fantasy about how quests can become larger than one intended. This one deserves to be remembered.

Harry Turtledove’s It’s the End Of The World As We Know It, and We Feel Fine looks as whimsical as its title, but there’s a serious SFnal point about the wages of (non)-domestication inside it. I think his future would actually be a nightmare of gentled humans being systematically abused by throwbacks, but – perhaps this is the world we already live in…

Krista Hoeppner Leany’s Killing Curses: A Caught-Heart Quest is not terrible, but by trying so hard to avert any recognizable fantasy tropes it becomes over-clever and unengaging.

Peter Watts’s Firebrand could be a lesson to all the authors of muddled, pointless, defective science fiction in this anthology about how to do it right. A disturbingly plausible premise about human spontaneous combustion is pursued with inexorable logic and dark humor.

Maureen McHugh’s The Memory Book is a dark, well-executed fantasy about Victorian voodoo. At best a read-once, alas.

Howard Waldrop’s The Dead Sea-bottom Scrolls is an entertaining but slight tale of windsailing on an alternate Mars that really had Martians. Aside from raising a mild chuckle I didn’t really see a point here.

Karin Tidbeck’s A Fine Show on the Abyssal Plain is another dark fantasy about the collapse of the fourth wall around a very strange theatrical troupe. Another well-written read-once.

Linda Nagata’s Out in the Dark is much more substantial. It incorporates some speculative technologies we’ve seen before in SF for body modification and self-duplication with a suggestion that some of their more troubling implications might be treated as crimes against unitary personhood that need to be policed against. But that’s a model that could, under some circumstances, produce injustices – and what’s an honest cop to do?

Naim Kabir’s On the Origin of Song is a wildly inventive fantasy full of vivid, almost Vancian imagery. One could milk a novel, and a lesser writer might have milked several, out of this setting.

Tang Fei’s Call Girl is yet another over-clever cloud of nothing much. The only way the story makes any sense at all is if all the characters are embedded in a giant VR after the fashion of the Matrix movies, but if this is so no interesting consequences are ever drawn from it.

Christopher Barzak’s Paranormal Romance isn’t even clever. It tries to be cute, but you can see every plot twist coming a mile off. Yeah, of course the witch’s blind date is a werewolf, etc weary cetera. Yawn.

Yugimi Okawa’s Town’s End is a fantasy premised on creatures of Japanese mythology needing a dating service to find men. A transparent and sad allegory of Japan’s dire demographic situation, but lovely and a bit haunting nevertheless.

Ian R. MacLeod’s The Discovered Country looks like a political allegory of an angry man determined to destroy the virtual paradise of the post-mortal idle rich, but it has a sting in its tail: when reality is virtual you may not even be able to trust your own memories.

Alan DeNiro’s The Wildfires of Antarctica is a middling amount of sound and fury about nothing much. Sophont art turns on the dissipated patron that bought it…boring and obvious.

Eleanor Arnason’s Kormak the Lucky finishes the anthology strong with a steampunkish take on Norse and Irish mythology.

If I believed the title of this anthology, I’d have to think the SF field was in desperate shape and fantasy barely better off. There are maybe five of the SF stories that will be worth remembering in a decade, and at best a few more of the fantasies. The rest is like wallpaper – busy, clever, and flat – except for the few pieces that are actively bad.

I’d ask what the anthologist was thinking, but since I’ve seen the author list on one of his other anthologies I don’t have to guess. For truth in advertising, this should probably have been titled “Rich Horton Recruits Mainly From His Usual Pool of Writers There Are Good Reasons I’ve Never Heard Of”. And far too many of them are second-raters who, if they ever knew how to write a decent F/SF story, have given that up to perform bad imitations of literary fiction.

In SF all the writing skill in the world avails you naught unless you have an idea to wrap your plot and characters around. In fantasy you need to be able to reach in and back to the roots of folklore and myth. Without these qualities at the center an F/SF story is just a brittle, glossy surface over nothing. Way too many of these stories were superficial cleverness over vacuum.

Posted Fri Jul 11 21:54:29 2014 Tags:
I've been rambling-writing for a couple weeks now about multi-process architecture (MPA) as seen in applications such as Akonadi or Chrome. After covering both the up- and down-sides, I also wrote a bit about missed opportunities: things that should be possible with MPA but which are rarely seen in practice. I kept promising to write about my thoughts on solutions to the downsides and missed opportunities, and that's where we are now.

The answer is deceptively simple: green processes. These are like green threads, which a few people actually mentioned in the comments sections of those past blog entries. Like green threads, green processes are mimics of native processes but run in a virtual machine (VM) instead. Some of the benefits are similar: you can have far less overhead per process (Erlang's per-process overhead is just 309 words) and you can launch thousands of them even if you only have one CPU core to work with without grinding they system to a halt. More usefully, if you have a 4 core system the VM can schedule N processes in exactly 4 native threads making full utilization of the system while minimizing things like context switch costs. (That does trivialize the complexity of the task by summarizing it in a single sentence ... )

Unlike green threads, however, green processes provide separation of memory access and require message passing rather than shared memory objects. They also more naturally follow the failure semantics of processes, such as the ability to crash. That may seem like a trivial set of differences, but the implications are hugely significant.

For instance, with crashing processes you can limit (and in many cases simply get rid of entirely) defensive programming. This requires a suitable language to go with the VM, but with such a thing in hand code can be written that only works in known-good (or white-listed) states. Everything else causes a crash, and this gets propagated appropriately through the system.

That system can include process supervisors which can restart processes or kill related ones in response to failures. It should also be noted that one still wants exceptions as those are for a rather different use case: non-fatal errors with known causes. (Essentially white-listed undesired behaviors.)

With message passing being the only way to coordinate between processes, you also are a tiny step away from distributed applications. After all, it doesn't look any different to the process in the VM if the message came from a process in the same VM or from a process elsewhere. So you can now split up your application between multiple VMs on the same system or on completely different systems connected by a network.

This could even be done at runtime or as a configuration option. Consider a system where one process needs to use unsafe native code (more on that later) and the rest simply do their thing safely in the VM. That one process could be moved to a separate VM (complete with process supervision) to keep it away from the rest of the processes. If the native code takes down that process or the native code leads to a security vulnerability, you now have process separation at the native OS level. If that process only causes problems on some systems (say, a graphical app being run on systems with a particular vendors particularly crashtastic GPU drivers), then it could be moved out of process only such systems and kept in-process otherwise.

Due to the lightweight nature of green processes one can afford to break an application up into a massively concurrent system. Each bit of I/O can live in its own process, for instance. Spawning a process for each socket or file operation becomes reasonable. Synchronous finite state machines (FSM), very useful things that, when not forced into asynchronous behavior due to event loops, are very simple to write and manage, become second nature.

A VM with green processes ends up resolving, or at least noticeably improving on, nearly all the downsides of native processes while also making most of the missed opportunities low-hanging fruit, sometimes even for free (as seen with distributing processes). What impact could this have?

Let's look at Akonadi. It could be a hundred processes instead of the two dozen it currently is on my system (I have a lot of accounts ...), making the code much simpler in the process (no more async job and async FSM implementations) while having dramatically lower overhead. Not only would the per-process cost be lower, even with message passing the cost would be truly zero as objects (not just serialized memory buffers!) are passed using copy-on-write (COW) and/or reference counted storage. On smaller systems with only one or two cores, the entire application would automatically "collapse" down to a single-threaded application that would be nearly identical in nature (and therefore also in performance) to a purposefully single-threaded, single-process, async event driven application. This is a new avenue for scalablility. Another one would be in how remote Akonadi processes would come alone for free; want to run Akonadi on a server but access the data locally? Want to spread your Akonadi processes across a network of systems? No problem. Meanwhile, all the benefits of the multi-process system it currently enjoys, including robustness, would be retained.

Or how about Plasma. Every DataEngine, every model and every widget could live in its own process in the VM. Since it looks like one process to the native OS (because it is), the actual UI could be delegated to a specific thread and even on x.org it could paint all day even if a DataEngine or other component were to die. Installing a new Plasmoid, even one with compiled code, could be hot-reloaded without restarting the desktop shell. KRunner could be sucked into the main plasma-shell process without risking stability or robustness, shrinking the overall footprint of the system. In fact, all of the separate processes could be pulled into the same VM while retaining all of the current benefits, including re-use on other systems that don't want plasma-shell.

It isn't all picnic baskets and fluffy white clouds, however.

Running natively compiled C/C++/ASM code in your VM will crash the entire VM when that code segfaults. So if one were to use Qt, for example, from such a VM any crash in Qt would bring down the whole thing. The benefits are only offered to code running in the VM. Perhaps using multiple VMs for just those parts of the system would be a solution in some cases. Given the message passing of such a system, it is possible to even run native code applications external to the VM and have them appear inside the VM as any other local-to-the-VM process (to other processes in VM, anyways) by grafting the message passing protocol onto that native application.

C/C++ isn't particularly suited to being run in such a VM, at least not with today's tools. So either new languages are needed or we need new tools. Or both. A new language for such a VM would not be the worst of ideas, actually: look how QML has vastly improved life in the UI world. Similarly, a properly designed language could make application development much safer, much easier and much faster. (To those who live-and-breath Python/Ruby/Perl/etc. that's not news, I'm sure.) That does mean that some amount of application code would need to be rewritten to take advantage of such a VM. This is probably desirable in any case since most applications will need rethinking in terms of massive concurrency. If the VM supports easily binding in existing native code, this could even be done in stages. We know that can work as this is exactly how Plasma was transitioned from imperative QGraphicsView code to declarative QML code. Still, there would be a transition period.

Finally, such a VM is not trivial to do correctly. It ends up becoming a micro-operating-system in its own right with memory management and process schedulers. Care needs to be paid to how messages are passed to keep overhead low there, as well. Making such a thing would be a significant investment. One could almost certainly start with existing art, but a lot of work would still be required.

Speaking of existing art: as I was considering the "after convergence" questions earlier this year, I ended up looking around for systems already tackling the problems I saw related to MPA and I came across Erlang which does nearly all of the above. So if you are interested in seeing what this can look like in practice, I definitely recommend looking into it. It is not a perfect system, but it is about the only one I could find that wasn't an academic project that addressed these issues head-on. I think the original designers of the runtime were way ahead of their time.

Erlang itself is probably not 'the answer', however. It is an amazing system that is just fantastic for server side work. (On that note, I think it is a much better fit for Akonadi than C++ ever could be, or for Bodega than node.js ever could be.) However, it lacks some of the features I'd really like to see in such a system such as cross-VM process migration (non-trivial to implement properly, granted), it is not well suited to numeric processing (not an issue for most data-centric servers) and has some legacy issues related to things like strings (though that has come leaps and bounds in recent years as well). I don't care about syntax warts as they aren't that bad in Erlang and if you think they are then simply use the rather nicer Elixir that runs on the same VM.

However, a system designed specifically for the needs of client-side user interface code could be marvelous. Systems under the application would remain in C/C++ and the UI should be done declaratively (with e.g. QML), but the application could be something else entirely that makes writing the applications in between those two parts far easier and ...

... more importantly than easier development, gift them with super-powers current systems are unlikely to ever offer. Multi-process architecture, despite the inherent benefits like increased application robustness, is really just a stepping stone towards being able to do more interesting things.

With the premise of a massively-concurrent system with minimized costs and a consistent message passing system in place as axiomatic assumptions for future applications, we can begin to explore new possibilities that open up.

You see, after convergence, which allows us to forget that devices are somehow different from each other (without hobbling the user interface into stupidity in the process), we can start thinking about how to use all those devices as a single fabric, be they remote servers, you and your friend's phones, your phone and your boss' laptop .. be they located on the same or different network segments .. be they in a consistent or a dynamic set of states ..

Still, before plunging in that direction conceptually, there are useful insights remaining to be brought into this house of thought. Next I will be exploring methods of authentication.

Until then, consider this question: How many separate online accounts do you have?

(I bet almost everyone will get the answer to that one "wrong". *devilish smile*)
Posted Thu Jul 10 12:36:00 2014 Tags:

I have many things to tell you about wifi, but before I can tell you most of them, I have to tell you some basic things.

First of all, there's the question of transmit power, which is generally expressed in watts. You may recall that a watt is a joule per second. A milliwatt is 1/1000 of a watt. A transmitter generally can be considered to radiate its signal outward from a center point. A receiver "catches" part of the signal with its antenna.

The received signal power declines with the square of the radius from the transmit point. That is, if you're twice as far away as distance r, the received signal power at distance 2r is 1/4 as much as it was at r. Why is that?

Imagine a soap bubble. It starts off at the center point and there's a fixed amount of soap. As it inflates, the same amount of soap is stretched out over a larger and larger area - the surface area. The surface area of a sphere is 4 π r2.

Well, a joule of energy works like a millilitre of soap. It starts off at the transmitter and gets stretched outward in the shape of a sphere. The amount of soap (or energy) at one point on the sphere is proportional to
1 / 4 π r2.

Okay? So it goes down with the square of the radius.

A transmitter transmitting constantly will send out a total of one joule per second, or a watt. You can think of it as a series of ever-expanding soap bubbles, each expanding at the speed of light. At any given distance from the transmitter, the soap bubble currently at that distance will have a surface area of 4 π r2, and so the power will be proportional to 1 / that.

(I say "proportional to" because the actual formula is a bit messy and depends on your antenna and whatnot. The actual power at any point is of course zero, because the point is infinitely small, so you can only measure the power over a certain area, and that area is hard to calculate except that your antenna picks up about the same area regardless of where it is located. So although it's hard to calculate the power at any given point, it's pretty easy to calculate that a point twice as far away will have 1/4 the power, and so on. That turns out to be good enough.)

If you've ever done much programming, someone has probably told you that O(n^2) algorithms are bad. Well, this is an O(n^2) algorithm where n is the distance. What does that mean?

    1cm -> 1 x
    2cm -> 1/4 x
    3cm -> 1/9 x
    10cm -> 1/100 x
    20cm -> 1/400 x
    100cm (1m) -> 1/10000 x
    10,000cm (100m) -> 1/100,000,000 x

As you get farther away from the transmitter, that signal strength drops fast. So fast, in fact, that people gave up counting the mW of output and came up with a new unit, called dBm (decibels times milliwatts) that expresses the signal power logarithmically:

    n dBm = 10n/10 mW

So 0 dBm is 1 mW, and 30 dBm is 1W (the maximum legal transmit power for most wifi channels). And wifi devices have a "receiver sensitivity" that goes down to about -90 dBm. That's nine orders of magnitude below 0; a billionth of a milliwatt, ie. a trillionth of a watt. I don't even know the word for that. A trilliwatt? (Okay, I looked it up, it's a picowatt.)

Way back in university, I tried to build a receiver for wired modulated signals. I had no idea what I was doing, but I did manage to munge it, more or less, into working. The problem was, every time I plugged a new node into my little wired network, the signal strength would be cut down by 1/n. This seemed unreasonable to me, so I asked around: what am I doing wrong? What is the magical circuit that will let me split my signal down two paths without reducing the signal power? Nobody knew the answer. (Obviously I didn't ask the right people :))

The answer is, it turns out, that there is no such magical circuit. The answer is that 1/n is such a trivial signal strength reduction that essentially, on a wired network, nobody cares. We have RF engineers building systems that can handle literally a 1/1000000000000 (from 30 dBm to -90 dBm) drop in signal. Unless your wired network has a lot of nodes or you are operating it way beyond distance specifications, your silly splitter just does not affect things very much.

In programming terms, your runtime is O(n) + O(n^2) = O(n + n^2) = O(n^2). You don't bother optimizing the O(n) part, because it just doesn't matter.

(Update 2014/07/14: The above comment caused a bit of confusion because it talks about wired networks while the rest of the article is about wireless networks. In a wireless network, people are usually trying to extract every last meter of range, and a splitter is a silly idea anyway, so wasting -3 dB is a big deal and nobody does that. Wired networks like I was building at the time tend to have much less, and linear instead of quadratic, path loss and so they can tolerate a bunch of splitters. For example, good old passive arcnet star topology, or ethernet-over-coax, or MoCA, or cable TV.)

There is a lot more to say about signals, but for now I will leave you with this: there are people out there, the analog RF circuit design gods and goddesses, who can extract useful information out of a trillionth of a watt. Those people are doing pretty amazing work. They are not the cause of your wifi problems.

Posted Thu Jul 10 05:15:49 2014 Tags:

Following Christian's Wayland in Fedora Update post, and after Hans fixed the touchpad acceleration, I've been playing with pointer acceleration in libinput a bit. The main focus was not yet on changing it but rather on figuring out what we actually do and where the room for improvement is. There's a tool in my (rather messy) github wip/ptraccel-work branchto re-generate the graphs below.

This was triggered by a simple plan: I want a configuration interface in libinput that provides a sliding scale from -1 to 1 to adjust a device's virtual speed from slowest to fastest, with 0 being the default for that device. A user should not have to worry about the accel mechanism itself, which may be different for any given device, all they need to know is that the setting -0.5 means "halfway between default and 'holy cow this moves like molasses!'". The utopia is of course that for any given acceleration setting, every device feels equally fast (or slow). In order to do that, I needed the right knobs to tweak.

The code we currently have in libinput is pretty much 1:1 what's used in the X server. The X server sports a lot more configuration options, but what we have in libinput 0.4.0 is essentially what the default acceleration settings are in X. Armed with the knowledge that any #define is a potential knob for configuration I went to investigate. There are two defines that are labelled as adjustible parameters:

  • DEFAULT_THRESHOLD, set to 0.4
  • DEFAULT_ACCELERATION, set to 2.0
But what do they mean, exactly? And what exactly does a value of 0.4 represent?
[side-note: threshold was 4 until I took the constant multiplier out, it's now 0.4 upstream and all the graphs represent that.]

Pointer acceleration is nothing more than mapping some input data to some potentially faster output data. How much faster depends on how fast the device moves, and to get there one usually needs a couple of steps. The trick of course is to make it predictable, so that despite the acceleration, your brain thinks that the visible cursor is an extension of your hand at all speeds.

Let's look at a high-level outline of our pointer acceleration code:

  • calculate the velocity of the current movement
  • use that velocity to calculate the acceleration factor
  • apply accel to dx/dy
  • smoothen out the dx/dy to avoid abrupt changes between two events

Calculating pointer speed

We don't just use dx/dy as values, rather, we use the pointer velocity. There's a simple reason for that: dx/dy depends on the device's poll rate (or interrupt frequency). A device that polls twice as often sends half the dx/dy values in each event for the same physical speed.

Calculating the velocity is easy: divide dx/dy by the delta time. We use a set of "trackers" that store previous dx/dy values with their timestamp. As long as we get movement in the same cardinal direction, we take those into account. So if we have 5 events in direction NE, the speed is averaged over those 5 events, smoothing out abrupt speed changes.

The acceleration function

The speed we just calculated is passed to the acceleration function to calculate an acceleration factor.

Figure 1: Mapping of velocity in unit/ms to acceleration factor (unitless). X axes here are labelled in units/ms and mm/s.
This function is the only place where DEFAULT_THRESHOLD/DEFAULT_ACCELERATION are used, but they mostly just stretch the graph. The shape stays the same.

The output of this function is a unit-less acceleration factor that is applied to dx/dy. A factor of 1 means leaving dx/dy untouched, 0.5 is half-speed, 2 is double-speed.

Let's look at the graph for the accel factor output (red): for very slow speeds we have an acceleration factor < 1.0, i.e. we're slowing things down. There is a distinct plateau up to the threshold of 0.4, after that it shoots up to roughly a factor of 1.6 where it flattens out a bit until we hit the max acceleration factor

Now we can also put units to the two defaults: Threshold is clearly in units/ms, and the acceleration factor is simply a maximum. Whether those are mentally easy to map is a different question.

We don't use the output of the function as-is, rather we smooth it out using the Simpson's rule. The second (green) curve shows the accel factor after the smoothing took effect. This is a contrived example, the tool to generate this data simply increased the velocity, hence this particular line. For more random data, see Figure 2.

Figure 2: Mapping of velocity in unit/ms to acceleration factor (unitless) for a random data set. X axes here are labelled in units/ms and mm/s.
For the data set, I recorded the velocity from libinput while using Firefox a bit.

The smoothing takes history into account, so the data points we get depend on the usage. In this data set (and others I tested) we see that the majority of the points still lie on or close to the pure function, apparently the delta doesn't matter that much. Nonetheless, there are a few points that suggest that the smoothing does take effect in some cases.

It's important to note that this is already the second smoothing to take effect - remember that the velocity (may) average over multiple events and thus smoothens the input data. However, the two smoothing effects somewhat complement each other: velocity smoothing only happens when the pointer moves consistently without much change, the Simpson's smoothing effect is most pronounced when the pointer moves erratically.

Ok, now we have the basic function, let's look at the effect.

Pointer speed mappings

Figure 3: Mapping raw unaccelerated dx to accelerated dx, in mm/s assuming a constant pysical device resolution of 400 dpi that sends events at 125Hz. dx range mapped is 0..127
The graph was produced by sending 30 events with the same constant speed, then dividing by the number of events to reduce any effects tracker feeding has at the initial couple of events.

The two lines show the actual output speed in mm/s and the gain in mm/s, i.e. (output speed - input speed). We can see that the little nook where the threshold kicks in and after the acceleration is linear. Look at Figure 1 again: the linear acceleration is caused by the acceleration factor maxing out quickly.

Most of this graph is theoretical only though. On your average mouse you don't usually get a delta greater than 10 or 15 and this graph covers the theoretical range to 127. So you'd only ever be seeing the effect of up to ~120 mm/s. So a more realistic view of the graph is:

Figure 4: Mapping raw unaccelerated dx to accelerated dx, see Figure 3 for details. Zoomed in to a max of 120 mm/s (15 dx/event).
Same data as Figure 3, but zoomed to the realistic range. We go from a linear speed increase (no acceleration) to a quick bump once the threshold is hit and from then on to a linear speed increase once the maximum acceleration is hit.

And to verify, the ratio of output speed : input speed:

Figure 5: Mapping of the unit-less gain of raw unaccelerated dx to accelerated dx, i.e. the ratio of accelerated:unaccelerated.

Looks pretty much exactly like the pure acceleration function, which is to be expected. What's important here though is that this is the effective speed, not some mathematical abstraction. And it shows one limitation: we go from 0 to full acceleration within really small window.

Again, this is the full theoretical range, the more realistic range is:

Figure 6: Mapping of the unit-less gain of raw unaccelerated dx to accelerated dx, i.e. the ratio of accelerated:unaccelerated. Zoomed in to a max of 120 mm/s (15 dx/event).
Same data as Figure 5, just zoomed in to a maximum of 120 mm/s. If we assume that 15 dx/event is roughly the maximum you can reach with a mouse you'll see that we've reached maximum acceleration at a third of the maximum speed and the window where we have adaptive acceleration is tiny.

Tweaking threshold/accel doesn't do that much. Below are the two graphs representing the default (threshold=0.4, accel=2), a doubled threshold (threshold=0.8, accel=2) and a doubled acceleration (threshold=0.4, accel=4).

Figure 6: Mapping raw unaccelerated dx to accelerated dx, see Figure 3 for details. Zoomed in to a max of 120 mm/s (15 dx/event). Graphs represent thresholds:accel settings of 0.4:2, 0.8:2, 0.4:4.
Figure 7: Mapping of the unit-less gain of raw unaccelerated dx to accelerated dx, see Figure 5 for details. Zoomed in to a max of 120 t0.4 a4 (15 dx/event). Graphs represent thresholds:accel settings of 0.4:2, 0.8:2, 0.4:4.
Doubling either setting just moves the adaptive window around, it doesn't change that much in the grand scheme of things.

Now, of course these were all fairly simple examples with constant speed, etc. Let's look at a diagram of what is essentially random movement, me clicking around in Firefox for a bit:

Figure 8: Mapping raw unaccelerated dx to accelerated dx on a fixed random data set.
And the zoomed-in version of this:
Figure 9: Mapping raw unaccelerated dx to accelerated dx on a fixed random data set, zoomed in to events 450-550 of that set.
This is more-or-less random movement reflecting some real-world usage. What I find interesting is that it's very hard to see any areas where smoothing takes visible effect. the accelerated curve largely looks like a stretched input curve. tbh I'm not sure what I should've expected here and how to read that, pointer acceleration data in real-world usage is notoriously hard to visualize.

Summary

So in summary: I think there is room for improvement. We have no acceleration up to the threshold, then we accelerate within too small a window. Acceleration stops adjusting to the speed soon. This makes us lose precision and small speed changes are punished quickly.

Increasing the threshold or the acceleration factor doesn't do that much. Any increase in acceleration makes the mouse faster but the adaptive window stays small. Any increase in threshold makes the acceleration kick in later, but the adaptive window stays small.

We've already merged a number of fixes into libinput, but some more work is needed. I think that to get a good pointer acceleration we need to get a larger adaptive window [Citation needed]. We're currently working on that (and figuring out how to evaluate whatever changes we come up with).

A word on units

The biggest issue I was struggling with when trying to understand the code was that of units. The code didn't document used units anywhere but it turns out that everything was either in device units ("mickeys"), device units/ms or (in the case of the acceleration factors) was unitless.

Device units are unfortunately a pretty useless base entity, only slightly more precise than using the length of a piece of string. A device unit depends on the device resolution and of course that differs between devices. An average USB mouse tends to have 400 dpi (15.75 units/mm) but it's common to have 800 dpi, 1000 dpi and gaming mice go up to 8200dpi. A touchpad can have resolutions of 1092 dpi (43 u/mm), 3277 dpi (129 u/mm), etc. and may even have different resolutions for x and y.

This explains why until commit e874d09b4 the touchpad felt slower than a "normal" mouse. We scaled to a magic constant of 10 units/mm, before hitting the pointer acceleration code. Now, as said above the mouse would likely have a resolution of 15.75 units/mm, making it roughly 50% faster. The acceleration would kick in earlier on the mouse, giving the touchpad and the mouse not only different speeds but a different feel altogether.

Unfortunately, there is not much we can do about mice feeling different depending on the resolution. To my knowledge there is no way to query the resolution on a device. But for absolute devices that need pointer acceleration (i.e. touchpads) we can normalize to a fake resolution of 400 dpi and base the acceleration code on that. This provides the same feel on the mouse and the touchpad, as much as that is possible anyway.

Posted Thu Jul 10 01:47:00 2014 Tags:

I had already intended for this next post to be a discussion of why people seem to suddenly disappear after they go to work for certain large companies. But then, last week, I went and made an example of myself.

Everything started out normally (the usual bit of attention on news.yc). It then progressed to a mention on Daring Fireball, which was nice, but okay, that's happened before. A few days later, though, things started going a little overboard, as my little article about human nature got a company name attached to it and ended up quoted on Business Insider and CNet.

Now don't get me wrong, I like fame and fortune as much as the next person, but those last articles crossed an awkward threshold for me. I wasn't quoted because I said something smart; I was quoted because what I said wasn't totally boring, and an interesting company name got attached. Suddenly it was news, where before it was not.

Not long after joining a big company, I asked my new manager - wow, I had a manager for once! - what would happen if I simply went and did something risky without getting a million signoffs from people first. He said something like this, which you should not quote because he was not speaking for his employer and neither am I: "Well, if it goes really bad, you'll probably get fired. If it's successful, you'll probably get a spot bonus."

Maybe that was true, and maybe he was just telling me what I, as a person arriving from the startup world, wanted to hear. I think it was the former. So far I have received some spot bonuses and no firings, but the thing about continuing to take risks is my luck could change at any time.

In today's case, the risk in question is... saying things on the Internet.

What I have observed is that the relationship between big companies and the press is rather adversarial. I used to really enjoy reading fake anecdotes about it at Fake Steve Jobs, so that's my reference point, but I'm pretty sure all those anecdotes had some basis in reality. After all, Fake Steve Jobs was a real journalist pretending to be a real tech CEO, so it was his job to know both sides.

There are endless tricks being played on everyone! PR people want a particular story to come out so they spin their press releases a particular way; reporters want more conflict so they seek it out or create it or misquote on purpose; PR people learn that this happens so they become even more absolutely iron-fisted about what they say to the press. There are classes that business people at big companies can take to learn to talk more like politicians. Ironically, if each side would relax a bit and stop trying so hard to manipulate the other, we could have much better and more interesting and less tabloid-like tech news, but that's just not how game theory works. The first person to break ranks would get too much of an unfair advantage. And that's why we can't have nice things.

Working at a startup, all publicity is good publicity, and you're the underdog anyway, and you're not publicly traded, so you can be pretty relaxed about talking to the press. Working at a big company, you are automatically the bad guy in every David and Goliath story, unless you are very lucky and there's an even bigger Goliath. There is no maliciousness in that; it's just how the story is supposed to be told, and the writers give readers what they want.

Which brings me back to me, and people like me, who just write for fun. Since I work at a big company, there are bunch of things I simply should not say, not because they're secret or there's some rule against saying them - there isn't, as far as I know - but because no matter what I say, my words are likely to be twisted and used against me, and against others. If I can write an article about Impostor Syndrome and have it quoted by big news organizations (to their credit, the people quoting it so far have done a good job), imagine the damage I might do if I told you something mean about a competitor, or a bug, or a missing feature, or an executive. Even if, or especially if, it were just my own opinion.

In the face of that risk - the risk of unintentionally doing a lot of damage to your friends and co-workers - most people just give up and stop writing externally. You may have noticed that I've greatly cut back myself. But I have a few things piling up that I've been planning to say, particularly about wifi. Hopefully it will be so technically complicated that I will scare away all those press people.

And if we're lucky, I'll get the spot bonus and not that other thing.

Posted Tue Jul 8 23:05:01 2014 Tags:

World of Fire (James Lovegrove; Solaris) is a a promising start to a new SF adventure series, in which a roving troubleshooter tackles problems on the frontier planets of an interstellar civilization.

Dev Harmer’s original body died in the Frontier War against the artificial intelligences of Polis+. Interstellar Security Solutions saved his mind and memories; now they download him into host bodies to run missions anywhere there are problems that have local law enforcement stumped. He dreams of the day the costs of his resurrection are paid off and he can retire into a reconstructed copy of his real body; until then, he’s here to take names and kick ass.

When this sort of thing is done poorly it’s just Mickey Spillane with rayguns. When it’s done well the SFnal setting is crucial to the story, and there’s a real puzzle (or a series of them) driving the plot.

In this case it’s done well. The expected quotas of action, fight scenes, hairbreadth escapes, and tough-guy banter are present. The prose and characterization are competent. The worldbuilding and puzzle elements are better than average. An ambitious pathbreaking work of SF it is not, but good value for your entertainment money it certainly is – good enough that I now want to investigate Lovegrove’s backlist.

I’ll look forward to the sequels.

Posted Tue Jul 8 12:12:33 2014 Tags:

As I write, the author of The Chaplain’s War (Brad Torgerson; Baen) has recently been one of the subjects of a three-minute hate by left-wingers in the SF community, following Larry Correia’s organization of a drive to get Torgerson and other politically incorrect writers on the Hugo ballot. This rather predisposed me to like his work sight unseen; I’m not a conservative myself, but I dislike the PC brigade enough to be kindly disposed to anyone who gives them apoplectic fits.

Alas, there’s not much value here. Much of it reads like a second-rate imitation of Starship Troopers, complete with lovingly detailed military-training scenes and hostile bugs as opponents. And the ersatz Heinlein is the good parts – the rest is poor worldbuilding, even when it’s not infected by religious sentiments I consider outright toxic.

Harrison Barlow is a chaplain’s assistant in an Earth military that is losing a war with mantis-like aliens bent on wiping out humanity. He and a remnant of the fleet are penned up on a Mantis-held planet, and the force-field walls are literally closing in. Then, the reason they were not instantly wiped out after losing their battle is revealed when Barlow is questioned by a Mantis anthropologist he comes to think of as the Professor.

The Mantes do not understand human religion. They have previously wiped out two other sophont species who engaged in religious practices. The Professor is of a faction among them now thinks this was over-hasty and that some effort should be made to understand “faith” before humanity is extinguished.

In the novel’s first major event, Barlow – with nothing to lose but his life – refuses to answer the Professor’s questions except on the condition that the Mantes call a truce. Much to his own astonishment, this actually happens; Barlow is repatriated and celebrated as humanity’s only successful negotiator with the Mantes.

The rest of the novel cross-cuts between (on the one hand) flashbacks to Barlow’s boot-camp experiences and the events leading up to his crucial meeting with the Professor, and (on the other) the events which follow on a Mantis decision to break the truce while Barlow and his superiors are negotiating with the Queen Mother who initiated the war.

What follows is deeply flawed as SF even if you’re not put off by Torgerson’s religious evangelism. The Mantes are too obviously authorial sock puppets; they (and the Queen Mother in particular) swing too readily and rapidly from being profoundly alien to seeming excessively human-like in psychology considering the given details of their biology and society.

By the time the Queen Mother begins having pangs of conscience over her previous behavior, believability has already essentially collapsed. The Mantes have become humans in funny-hat carapaces. Lost is any of the illusion, so necessary in fiction but especially in SF, that the author’s characters and his setting have any causal autonomy.

The ensuing redemption narrative is so obviously manipulative that it’s wince-inducing. It gets worse as it goes on, and the ending is positively mawkish. Even a religious person should squirm when an apologia is this clumsy.

Then we get to the essential anti-rationality of the author’s religion. There are several crucial beats in the plot at which the day is saved by what the author none-too-subtly hints is divine intervention; I think this is a direct crime against science fiction’s core promise that the universe is rationally knowable. But this book is a tepid mess even if you don’t see that as a problem.

Posted Mon Jul 7 13:36:46 2014 Tags:

    If you are so smart why are twiddling around bits [...] for breadcrumbs when you could have started your own company or gotten into academia?

    -- Someone on the Internet
    in response to my post about smart people

That's an excellent question, actually. Okay, it could maybe have been phrased more politely, and I won't even begin to answer the question about academia, and in fact the breadcrumbs are prepared by professional chefs and are quite delicious. (I'm not even kidding.) But that question about starting my own company, that's a good question, because I've done that a few times before and this time I didn't.

The answer is that I had a conversation like this:

Me: I want to make wifi routers. I think they're all terrible, and they're all commoditized, and all competing on price. Someone needs to do to wifi routers what the iPhone did to phones.

Friend: That sounds fun. You should start a startup.

Me: Right, I was going to do that.

Friend: And then recruit me to it.

Me: Er, yeah, I will definitely get back to --

Friend: Or we could start it together! You should come to New York and convince me.

Me: Um. Well, you see, the first rule of starting a startup is you don't waste money on unnecessary --

Friend: I have an idea!

Me: Oh good.

Friend: I work at a big company. You should come interview here.

Me: I don't see how that will help at all.

Friend: It's simple. They pay for the flight, and you come for an interview, then stay for a few days and you convince me to work with you.

Me: That sounds a bit unethical.

Friend: Nonsense! It's totally fine as long as you promise to hear them out. That's all any job interview is, for either side. No commitments. You just need to come with an open mind.

Me: Hmm.

Friend: Plus if you get hired, I could get a bonus just for referring you!

Me: Oh, okay then.

So off I went to New York. tl;dr he got a referral bonus and I learned to never, ever go into any situation with an open mind.

Just kidding.

Okay, partly kidding.

But the real reason I decided not to start this startup was as follows: I couldn't figure out a business model for selling the world's most ultimate consumer wifi router. I knew how to build one, but not how to sell one. The problem was the ecosystem wasn't really there. A now-small subset of customers go to the store and buy a router based on brand name and price; they don't recognize most brand names and don't know what price is best, so they pick one randomly. Generally they will start by buying a terrible router for $30, and find out that it's terrible, and if they can afford it, they'll switch to a possibly-less-terrible one for $100+. But sucks to be them, because if they buy a *really* expensive one for, say, $200+, it's often even worse because it's bleeding edge experimental.

And anyway, that whole segment is not the one you want to be in, because nowadays ISPs all provide a wifi router along with every account, and most people take what they're given and don't bother to ever replace it. So if you want to change the world of wifi routers, you have to have a partnership with an ISP. But ISPs don't want to buy the best wifi router; they want to buy the cheapest wifi router that meets specifications. Sure, they'd probably pay a bit extra for a router with fewer bugs that causes fewer tech support calls... that's just good economics. But how will your tiny startup prove that your router causes fewer tech support calls? There's no chance.

And so the cycle continues: ISPs buy cheap-o routers and give them to you, and they crash and you fix them by turning them off and on again, and there's bufferbloat everywhere, and the Internet is a flakey place, and so on, forever.

I couldn't figure out how to fix that so I took a job doing something else.

Posted Mon Jul 7 05:51:25 2014 Tags: