Recommended Links for 2015-11-06

It’s been forever since I updated the blog at all, and I do it with a linkdump. :) But it’s also a good chance to roll out a new theme, as I was getting sick of the dark one.

Here are some of the interesting things I’ve been reading lately.

  • Fail at Scale by Ben Maurer at Facebook

    I found this article on failures in distributed systems at Facebook really interesting. It includes information on common observed failure modes, advice for preventing failures from cascading across a large system, improvements in monitoring dashboards, and a description of Facebook’s incident review methodology. There are a lot of really good practical lessons here, and I highly recommend reading this article.

    One small section that stood out to me called out the fact that human-initiated changes are a major source of failure, an insight I’ve seen in a number of places lately:

    These two data points seem to suggest that when Facebook employees are not actively making changes to infrastructure because they are busy with other things (weekends, holidays, or even performance reviews), the site experiences higher levels of reliability. We believe this is not a result of carelessness on the part of people making changes but rather evidence that our infrastructure is largely self-healing in the face of non-human causes of errors such as machine failure.

  • Let’s talk about logging, by Dave Cheney

    I’m actually sharing this link for two reasons: because it’s thought-provoking, and because I disagree with it so much! Cheney makes some interesting arguments for the idea that there are only two types of logs: debug logs that programmers care about, and info logs that users care about. Other log levels are unneeded.

    My disagreement could probably be expanded into a whole blog post. But suffice it to say that I think having levels of logging is extremely useful from an operational perspective and makes monitoring and filtering those logs a lot easier. In my opinion, collapsing these into “debug” and “info” would only result in a lot of custom tags in the text of the logs, and a lot more work for regex parsers in the monitoring system. :)

  • A Case Study - Scaling Legacy Code on Next Generation Platforms, by William Roshan Quadros at SNL for IMR24

    This paper is an interesting little case study about how to scale HPC codes to platforms with new processor technologies and a higher level of parallelism – i.e., the new Trinity system at LANL. I expect to have reason to re-read this a few more times.

  • Disaggregated disk, by Dan Luu

    This is a good read about how the difference in latency between different types of data transfers (disk, network, RDMA, etc) help to determine what kind of system design will perform best. For example, storage can often be located on a different machine rather than locally because network latency is often much less than the latency of a disk seek. Very much worth the read.

  • Complexity budgets, by Jamie Brandon

    A good short post on designing systems to reduce complexity and maximize the ability of a team to understand the system, not just optimizing each individual part of the system in isolation.

  • Blue Monday, by Laurie Penny

    An interesting and disturbing little near-future science fiction story, on Vice’s Motherboard site. (Which site has been impressing me a lot lately.)

What Should an Educated Person Know of Science?

Cheryl Rofer asked a thought-provoking question on Twitter today:

While she’s already gotten a ton of good answers, I couldn’t really manage anything I thought was interesting in 140 characters. Among other things, I kept thinking of different answers, and I didn’t want to bombard her with dozens of tweets. :)

But it is a fascinating question, and I wanted to record some of the answers that popped into my head. This seems as good a place as any.

  • Science is a process for answering questions. In general, it consists of carefully studying something you don’t understand, like an object or a process or a living thing; making guesses about the answers to your questions (such a guess is usually called a “hypothesis”); and then trying to figure out if your guess is correct, either by making more observations, or by carrying out some kind of test or experiment which is designed to tell you if your guess was wrong.

  • Science is really hard to do well. Most of the time, when you start studying something, it turns out to be hugely more complicated than you thought it was. When you start trying to test your guesses about how the world works, you’ll often find there are lots of complicating details which make it hard to do a good test.

  • Scientists are people! Most of the time they are extremely careful, and they try to eliminate sources of error or bias in their work. But this is also very difficult to do, so the science they produce is usually not perfect or completely correct.

  • Science is the best method we’ve found so far for building reliable knowledge about the world. Despite how hard it is and how easy it is to make mistakes. It can take a very long time to find and fix our misconceptions, but over time our society seems to make good progress on this.

  • The world acts differently at different scales. For example: many of the same general processes are involved in global climate, local weather, and how the air inside your house circulates. But the results are very different. Depending on what you’re studying, this might affect how well your small-scale experiment explains something much larger.

  • Math provides a very effective way to speak precisely about scientific observations or predictions. This works very well for some sciences like physics, chemistry, or computer science; it works less well for others, such as anthropology or sociology. Just because something is not expressed in terms of math or numbers, does not mean it isn’t science.

  • When you see a news report about science, remember that the journalist is trying to tell a good story that they think will make sense to their audience. The scientist, speaking to other scientists, is likely to tell a much more limited story with a lot more doubt in it. That doesn’t mean the story is wrong! But it does mean that the answers may not be as certain as it appears in the story.

  • One of the tricks to understanding science is to know that the answers are always in doubt, but that some answers are more certain than others. Doubt is not a binary choice, where you think you know the answer or you don’t; it’s a sliding scale where you have a lot of evidence for some answers, but less evidence or conflicting evidence for others.

The rest of the answers I thought of were either due to current events (i.e. “global warming is real”), restatements of grade school science (“the Earth orbits around the Sun”), or things like “people should understand the laws of thermodynamics”. I’ll spare you a list of answers of that type, as in the best case they are boring, and in the worst case they just reveal my own biases about what I think is important in terms of science trivia. :)

Linkdump for 2015-07-14

I don’t make these posts to claim they’re the “best links from the past week” or anything like that. So instead, let’s just say they’re some of the more interesting links I’ve read recently enough to want to post them. :)

Top picks

Other interesting links

Recent Favorite SALT Talks

Apropos of my comments about The Clock of the Long Now in the recent reading post, here are a few of my recent favorites from the Long Now Foundation’s Seminars about Long-Term Thinking:

Recently Read Books, 2015-06-28

  • Chaos: Making a New Science, by James Gleick.

    I’ve read a few of James Gleick’s histories of science and scientists, including Genius, Isaac Newton, and The Information, but I somehow missed Chaos up until now. As always, Gleick delivers a fascinating, well-researched history, and I greatly enjoyed it. Indeed, I was impressed by the fact that he could maintain an interesting style for a popular audience while providing enough detail about some of the math that I could reproduce some of the fractals and graphs he refers to in IPython! Highly recommended.

  • Thinking in Systems: A Primer, by Donella Meadows.

    This book is a well-written, easy to understand introduction to the theory of dynamic systems. At least, I found it easy to read and understand, and I’m assured by reviews from those with more systems theory experience that it’s a decent basic text. :) It helped clarify some other recent reading, and provided some structure for some other problems I’ve been thinking about. If you’re reading this and can suggest future reading on this topic, please feel free to send me a note.

  • The Clock of the Long Now, by Stewart Brand.

    The Long Now Foundation has long provided some of the more interesting material about long-term thinking, and I’m a big fan of the podcast recordings of their seminar series. During a recent visit to San Francisco we stopped in at The Interval, their public bar/salon, and I picked up a copy of Stewart Brand’s book about the idea of th Long Now.

    Having listened to so many of the seminars where Brand questions the speakers at the end, it’s clear that the essays in this book are from early in the project’s history: I think his thinking has evolved a bit, and it’s possible to see where ideas from this book are more developed in later talks or essays.

    However, I think it’s still well worth reading. The quotes on the back of the book will encourage you to read it slowly, despite how short it is, and I think that’s a good idea; there’s a high idea-density in these essays, and it’s worth taking time to think. I don’t know that I agree with everything found here, or even its bulk; but it definitely made me think throughout.

  • Seveneves, by Neal Stephenson.

    Another very good book from Stephenson. As always very detailed, heavy on exposition but is clearly enjoying himself so much it’s infectious. Not one of my favorites – I enjoyed Anathem and Cryptonomicon much more – but also nowhere near as disappointing as Reamde. Solid recommendation for anyone who enjoys books about the end of the world; books about engineers solving ridiculous problems; or fans of very detailed near-future science fiction.

  • Slow Bullets, by Alastair Reynolds.

    I’ve always found Alastair Reynolds to be kind of hit-or-miss; for example, I loved Chasm City and House of Suns, but found his Revelation Space series disappointing. Slow Bullets has an interesting premise, of soldiers from a war long over being awoken on a decaying starship, but I didn’t really connect with the characters or enjoy the execution of the story.

  • The Martian, by Andy Weir.

    Really fun excellent science fiction adventure for those who enjoy tales of extreme engineering. The xkcd is pretty much accurate.

  • The Big Roads, by Earl Swift.

    I’m still in progress on this one, but it’s a fascinating story and a lot of fun to read. Like with Chaos, I really enjoy histories of science and engineering; but I didn’t think that a civil engineering history would be quite so enjoyable. One of the things that’s surprising me is how relatively new so much of our infrastructure is, with most of even the rural highways in America being built in the late 1800s or early 1900s. The decaying nature of our modern infrastructure seems to be less because it’s old, or poorly built, but more because we just demand so much from it and spend so little time or energy on its maintenance.