Saturday, September 27, 2014

What I'm reading, Aurora ATC edition

Amazingly, some of our relatives in Illinois, even those living in Downers Grove, hadn't heard about the events in Aurora. I think it's one of those bizarre events that affected a handful of people very significantly, some of those people many thousands of miles away from the incident, but didn't affect others even one whit.


  • FAA contractor charged with fire that halted Chicago flights
    "This is a nightmare scenario when we thought systems were in place to prevent it," said aviation analyst Joseph Schwieterman of DePaul University in Chicago. "Technology is advancing so fast that ... there's less of a need for air traffic control to be so geographically oriented. I think the FAA's going to find itself under a microscope."
  • Everything you need to know about the Shellshock Bash bug
    The risk centres around the ability to arbitrarily define environment variables within a Bash shell which specify a function definition. The trouble begins when Bash continues to process shell commands after the function definition resulting in what we’d classify as a “code injection attack”.
  • MySQL 5.7.5: GROUP BY respects functional dependencies!
    Most RDBMS-es implement the SQL92 behavior, and generate an error in case a non-aggregate expression appears in the SELECT-list but not the GROUP BY-clause. Because MySQL would not generate an error at all and instead would simply allow such queries while silently producing a non-deterministic result for such expressions, many users got bitten and frustrated.
  • Scaling NoSQL databases: 5 tips for increasing performance
    Virtualization can be great. It provides the flexibility to use a single machine for multiple purposes, with reasonable security for non-critical business data. Unfortunately, it also influences memory access speed, which is critical for some NoSQL databases. Depending on the hypervisor and the underlying hardware capabilities, it can add 20-200% penalty in accessing memory for NoSQL workloads. I have witnessed this in testing, and it is also documented by a number of industry benchmarks. Newer generation hardware helps with better support for hardware assisted memory management unit (MMU), but there is still a significant impact for workloads that generate a lot of Translation Lookaside Buffer (TLB) misses (as NoSQL databases are wont to do).
  • Why Scrum Should Basically Just Die In A Fire
    Of course, musing, considering, mulling things over, and coming to realizations all constitute a significant amount of the actual work in programming. It is impossible to track whether these realizations occur in the office or in the shower. Anecdotally, it's usually the shower. Story points, meanwhile, are completely made-up numbers designed to capture off-the-cuff estimates of relative difficulty. Developers are explicitly encouraged to think of story points as non-binding numbers, yet velocity turns those non-binding estimates into a number they can be held accountable for, and which managers often treat as a synonym for productivity. "Agile" software exists to track velocity, as if it were a meaningful metric, and to compare the relative velocity of different teams within the same organization.

    This is an actual thing which sober adults do, on purpose, for a living.

    "Velocity" is really too stupid to examine in much further detail, because it very obviously disregards this whole notion of "working software as a measure of progress" in favor of completely unreliable numbers based on almost nothing.


    Sacrificing "working software as a measure of progress" to meaningless numbers that your MBAs can track for no good reason is a pretty serious flaw in Scrum. It implies that Scrum's loyalty is not to the Agile Manifesto, nor to working software, nor high-quality software, nor even the success of the overall team or organization. Scrum's loyalty, at least as it pertains to this design decision, is to MBAs who want to point at numbers on a chart, whether those numbers mean anything or not.

  • Relativistic hash tables, part 1: Algorithms
    One might wonder whether the resizing of hash tables is common enough to be worth optimizing. As it turns out, picking the correct size for a hash table is not easy; the kernel has many tables whose size is determined at system initialization time with a combination of heuristics and simple guesswork. But even if the initial guess is perfect, workloads can vary over time. A table that was optimally sized may, after a change, end up too small (and thus perform badly) or too big (wasting memory). Resizing the table would fix these problems, but, since that is hard to do without blocking access to the table, it tends not to happen. The longer-term performance gains are just not seen to be worth the short-term latency caused by shutting down access to the table while it is resized.
  • How to Squeeze a Huge Ship Down a Tiny River
    Everything aligned on Monday, and the six captains set to work in the afternoon. Given the intense concentration needed to do the job, they worked in pairs for 90 minute shifts. One captain steered the bow, the other guided the stern. The unusual maneuvering system helps a ship this big precisely navigate tight turns and narrow squeezes, much like a tiller driver helps the driver of a hook-and-ladder firetruck navigate city streets.

    Spectators lining the river could be forgiven for thinking Quantum was headed upriver, given that it went downriver backward. Using the propellers to pull from the front offers better control than pushing from the back (the same is true for front wheel-drive cars). Tug boats, attached directly, rather than by a cable, to the bow and stern of the ship, provided extra control.

  • File systems, Data Loss and ZFS
    ZFS is able to protect all of these things between the disks and system memory, with each change protected after an IO operation (e.g. a write) returns from the kernel. This protection is enabled by ZFS’ disk format, which places all data into a Merkle tree that stores 256-bit checksums and is changed atomically via a two-stage transaction commit. No other major filesystem provides such guarantees.

    However, that is not to say that ZFS cannot lose data.

  • Another Patent Troll Slain. You Are Now Free To Rotate Your Smartphone.
    Rotatable owned a patent that it claimed covers the screen rotation technology that comes standard in just about every smartphone. You know, when you flip your device sideways and the screen shifts orientation from portrait mode to landscape mode? Like nearly all the apps in the Apple and Android app stores, Rackspace uses standard functionality provided by Apple’s libraries and Android open source software to provide this display feature in our mobile cloud applications.
  • The Dropbox terabyte conundrum
    When you move items to Transporter Library, they are moved off of your device and into the Transporter’s personal cloud. You are offloading files from your system, for hosting elsewhere. Accessing them is slow, of course, because they’re not actually on your device. But they’re also not taking up space on that tiny solid-state drive of yours.

    It’s a clever approach, and one that I hope Dropbox adopts—but I’m a little concerned that Dropbox is so committed to its metaphor that it won’t want to complicate it like this. Allowing direct disk-like access to Dropbox is very different than syncing files, so it might require major changes to Dropbox’s infrastructure. I can see how it might not be a development priority.

  • Liverpool beat Middlesbrough after 30-penalty Capital One Cup shoot-out
    It was the longest penalty shoot-out in the history of the League Cup, the previous record set at 9-8 on three occasions, and more extensive than the FA Cup’s highest total when Macclesfield beat Forest Green 11-10 in 2001. Of major English competitions only the Football League Trophy can equal it, also boasting a 14-13 shoot-out.

In other news, I made Hacker News!

For an essay I wrote last January.

But it was cool nonetheless.

And thanks, Kale, for including me in your newsletter!

No comments:

Post a Comment