Mike Loukides
Mike Loukides is Vice President of Content Strategy for O'Reilly Media, Inc. He's edited many highly regarded books on technical subjects that don't involve Windows programming. He's particularly interested in programming languages, Unix and what passes for Unix these days, and system and network administration. Mike is the author of System Performance Tuning", and a coauthor of "Unix Power Tools." Most recently, he's been fooling around with data and data analysis, languages like R, Mathematica, and Octave, and thinking about how to make books social.
Postmodern security
The real challenge going forward: we can't trust anything.
A few weeks ago, I wrote about postmodern computing, and characterized it as the computing in a world of distrust.
This morning, I read Steve Bellovin’s blog post, What Must We Trust? — Bellovin explains that “modern” (my word) security is founded on the idea of a “Trusted Computing Base” (TCB), defined (in part) in the United States’ Defense Department’s Orange Book. There were parts of a system that you had to trust, and you had to guard their integrity vigilantly: the kernel, certainly, but also specific configuration files, executables, and so on.
The TCB has always been problematic, particularly since (at least initially) it did not consider the problem of network connections. But networking aside, Bellovin argues that recent events have blown the idea of a “trusted” system to bits. We’ve seen attacks against (Bellovin’s list) batteries, webcams, USB, and more. If Andromedans (Bellovin doesn’t want to say NSA) have managed to infiltrate our disk drives, what can trust mean? And it would be naive to think that this stops with devices that have disk drives. Our devices, from Fitbits to data centers, have been pwnd even before they’re built. Read more…
What is DevOps (yet again)?
Empathy, communication, and collaboration across organizational boundaries.
I might try to define DevOps as the movement that doesn’t want to be defined. Or as the movement that wants to evade the inevitable cargo-culting that goes with most technical movements. Or the non-movement that’s resisting becoming a movement. I’ve written enough about “what is DevOps” that I should probably be given an honorary doctorate in DevOps Studies.
Baron Schwartz (among others) thinks it’s high time to have a definition, and that only a definition will save DevOps from an identity crisis. Without a definition, it’s subject to the whims of individual interest groups, and ultimately might become a movement that’s defined by nothing more than the desire to “not be like them.” Dave Zwieback (among others) says that the lack of a definition is more of a blessing than a curse, because it “continues to be an open conversation about making our organizations better.” Both have good points. Is it possible to frame DevOps in a way that preserves the openness of the conversation, while giving it some definition? I think so.
DevOps started as an attempt to think long and hard about the realities of running a modern web site, a problem that has only gotten more difficult over the years. How do we build and maintain critical sites that are increasingly complex, have stringent requirements for performance and uptime, and support thousands or millions of users? How do we avoid the “throw it over the wall” mentality, in which an operations team gets the fallout of the development teams’ bugs? How do we involve developers in maintenance without compromising their ability to release new software?
Beyond lab folklore and mythology
What the future of science will look like if we’re bold enough to look beyond centuries-old models.
Editor’s note: this post is part of our ongoing investigation into synthetic biology and bioengineering. For more on these areas, download the latest free edition of BioCoder.
Over the last six months, I’ve had a number of conversations about lab practice. In one, Tim Gardner of Riffyn told me about a gene transformation experiment he did in grad school. As he was new to the lab, he asked two more experienced scientists for their protocol: one said it must be done exactly at 42 C for 45 seconds, the other said exactly 37 C for 90 seconds. When he ran the experiment, Tim discovered that the temperature actually didn’t matter much. A broad range of temperatures and times would work.
In an unrelated conversation, DJ Kleinbaum of Emerald Cloud Lab told me about students who would only use their “lucky machine” in their work. Why, given a choice of lab equipment, did one of two apparently identical machines give “good” results for a some experiment, while the other one didn’t? Nobody knew. Perhaps it is the tubing that connects the machine to the rest of the experiment; perhaps it is some valve somewhere; perhaps it is some quirk of the machine’s calibration.
The more people I talked to, the more stories I heard: labs where the experimental protocols weren’t written down, but were handed down from mentor to student. Labs where there was a shared common knowledge of how to do things, but where that shared culture never made it outside, not even to the lab down the hall. There’s no need to write it down or publish stuff that’s “obvious” or that “everyone knows.” As someone who is more familiar with literature than with biology labs, this behavior was immediately recognizable: we’re in the land of mythology, not science. Each lab has its own ritualized behavior that “works.” Whether it’s protocols, lucky machines, or common knowledge that’s picked up by every student in the lab (but which might not be the same from lab to lab), the process of doing science is an odd mixture of rigor and folklore. Everybody knows that you use 42 C for 45 seconds, but nobody really knows why. It’s just what you do.
Despite all of this, we’ve gotten fairly good at doing science. But to get even better, we have to go beyond mythology and folklore. And getting beyond folklore requires change: changes in how we record data, changes in how we describe experiments, and perhaps most importantly, changes in how we publish results. Read more…
Announcing BioCoder issue 6
BioCoder 6: iGEM's first Giant Jamboree, an update from the #ScienceHack Hack-a-thon, the Open qPCR project, and more.
Once again, we’re interested in your ideas and in new content, so if you have an article or a proposal for an article, send it in to BioCoder@oreilly.com. We’re very interested in what you’re doing. There are many, many fascinating projects that aren’t getting media attention. We’d like to shine some light on those. If you’re running one of them — or if you know of one, and would like to hear more about it — let us know. We’d also like to hear more about exciting start-ups. Who do you know that’s doing something amazing? And if it’s you, don’t be shy: tell us.
Above all, don’t hesitate to spread the word. BioCoder was meant to be shared. Our goal with BioCoder is to be the nervous system for a large and diverse but poorly connected community. We’re making progress, but we need you to help make the connections.
Self-censorship is not the way forward
Marco Arment did an excellent job of offering constructive criticism to a company that he genuinely loves.
I was disappointed to see Marco Arment say he wishes he never wrote his post on Apple’s software quality, “Apple has lost the functional high ground.”
The point he made is one I’ve tweeted about (though not written about) a number of times over the years. The big problem facing Apple isn’t a deficit of innovation, but bitrot creeping into their codebase. You don’t have to look far to see it: for example, there’s a race condition in text handling that has been there since at least OS X 10.3.
The point needed to be made by someone who knows and loves Apple, someone who is a leader in their developer community, and someone who has a reputation for being fair and even-handed. That’s Marco. He did an excellent job of offering constructive criticism to a company that he genuinely loves.
Yes, there is a risk that anything you write will turn into a media storm. That’s a risk you have to live with; it’s unfortunate, but it’s not going away. It’s also important to say what needs to be said. Self-censorship is not the way forward. Read more…
Becoming data driven
DJ Patil and Hilary Mason's Data Driven: Creating a Data Culture is about building organizations that can take advantage of data.
I’m not going to summarize their work here: you should read it. It’s based on the realization that merely assembling a bunch of people who understand statistics doesn’t do the job. You end up with a group of data specialists on the margins of the organization, who don’t have the ability to do anything more than be frustrated. If you don’t develop a data culture, if people don’t understand the value of data and how it can be used to inform discussions, you can build all the dashboards and Hadoop clusters you want, but they won’t help you.
Data is a powerful tool, but it’s easy to jump on the data bandwagon and miss the benefits. Data Driven: Creating a Data Culture is about building organizations that can really take advantage of data. Is that organization yours? Read more…
The computing of distrust
A look at what lies ahead in the disenchanted age of postmodern computing.
Sometime last summer, I ran into the phrase “postmodern computing.” I don’t remember where, but it struck me as a powerful way to understand an important shift in the industry. What is different in the industry? How are 2014 and 2015 different from 2004 and 2005?
If we’re going to understand what “postmodern computing” means, we first have to understand “modern” computing. And to do that, we also have to understand modernism and postmodernism. After all, “modern” and “postmodern” only have meaning relative to each other; they’re both about a particular historical arc, not a single moment in time.
Some years back, I was given a history of St. Barbara’s Greek Orthodox Church in New Haven, carefully annotated wherever a member of my family had played a part. One story that stood out from early in the 20th century was AHEPA: the American-Hellenic Progressive Association. The mere existence of that organization in the 1920s says more about modernism than any number of literary analyses. In AHEPA, and in many other similar societies crossing many churches and many ethnic groups, people were betting on the future. The future is going to be better than the present. We were poor dirt farmers in the Old Country; now we’re here, and we’re going to build a better future for ourselves and our children. Read more…
One more word on drones: Warehouses
Drones might never find meaningful retail delivery work, but they might find practical employment in warehouses.
After writing my short post about the use of drones to deliver packages, it occurred to me that there’s one more realistic use case. Unfortunately (or not), this is a use case that you’ll never see if you’re not an Amazon employee. But I think it’s very realistic. And obviously, I just can’t get drones out of my head.
As I argued, I don’t think you’ll see drones for retail delivery, except perhaps as a high-cost, very conspicuous consumption frill. What could get more conspicuous? Drone pilots are expensive, and I don’t think we’ll see regulations that allow autonomous drones flying in public airspace any time soon. Drones also aren’t terribly fast, and even if you assume that the warehouses are relatively close to the customers, the number of trips a drone can make per hour are limited. There’s also liability, weather conditions, neighbors shooting the drones down, and plenty of other drawbacks.
These problems all disappear if you limit your use of drones to the warehouse itself. Don’t send the drone to the customer: that’s a significant risk for an expensive piece of equipment. Instead, use the drones within the warehouse to deliver items to the packers. Weather isn’t an issue. Regulation isn’t an issue; the FAA doesn’t care what you do inside your building. Autonomous flight isn’t just a realistic option, it’s preferable: one massive computing system can coordinate and optimize the flight paths of all the drones. Amazon probably has some of that system built already for its Kiva robots, and Amazon is rather good at building large computing architectures. Distance isn’t an issue. Warehouses are big, but they’re not that big, and something (or someone) has to bring the product to the packing station, whether it’s a human runner or a Kiva robot. Read more…
The revolution in biology is here, now
Biological products have always seemed far off. BioFabricate showed that they're not.
Installation view of The Living’s Hy-Fi, the winning project of The Museum of Modern Art and MoMA PS1’s 2014 Young Architects Program. Photograph by Kris Graves.
The products discussed at BioFabricate aren’t what I thought they’d be. I’ve been asked plenty of times (and I’ve asked plenty of times), “what’s the killer product for synthetic biology?” BioFabricate convinced me that that’s the wrong question. We may never have some kind of biological iPod. That isn’t the right way to think.
What I saw, instead, was real products that you might never notice. Bricks made from sand that are held together by microbes designed to excrete the binder. Bricks and packing material made from fungus (mycelium). Plastic excreted by bacteria that consume waste methane from sewage plants. You wouldn’t know, or care, whether your plastic Lego blocks are made from petroleum or from bacteria, but there’s a huge ecological difference. You wouldn’t know, or care, what goes into the bricks used in the new school, but the construction boom in Dubai has made a desert city one of the world’s largest importers of sand. Wind-blown desert sand isn’t useful for industrial brickmaking, but the microbes have no problem making bricks from it. And you may not care whether packing materials are made of styrofoam or fungus, but I despise the bag of packing peanuts sitting in my basement waiting to be recycled. You can throw the fungal packing material into the garden, and it will decompose into fertilizer in a couple of days. Read more…
Drone delivery: Real or fantasy?
For the time being, we won't see drone delivery outside of a few very specialized use cases.
I read with some interest an article on the Robotenomics blog about the feasibility of drone delivery. It’s an interesting idea, and the article makes a better case than anything I’ve seen before. But I’m still skeptical.
The article quotes direct operating costs (essentially fuel) that are roughly $0.10 for a 2-kilogram payload, delivered 10 kilometers. (For US-residents, that’s 4.4 pounds and about six miles). That’s reasonable enough.
The problem comes when he compares it to Amazon’s current shipping costs, of $2 to $8. But it sounds roughly like what Amazon pays to UPS or FedEx. And that’s not for delivering four pounds within a six-mile range. And it’s not just the fuel cost: it’s the entire cost, including maintenance, administrative overhead, executive bonuses, and (oh, yes) the driver’s salary. Read more…