Filed under: important | the bblog

come on up, get your extremely impractical ideas here

Samuel Bierwagen — 2012-05-01T13:25:01-04:00

So I've got a dumb idea, and in the hopes of getting it out of my head, I'm going to write a blog post about it.

In 2006, Daniel Rutter wrote about the "genset" option for the t/zero vaporware electric car. The basic idea was this: A plug-in hybrid, but with the gasoline engine on a trailer. If you're taking a short trip, then you don't take the genset with you, because you don't need the weight. If you're going on a long trip, then you hook up the trailer, and enjoy the long range and fast refueling that a gasoline engine gives you. (Note that this scheme means you'll have a fairly large genset sitting around at home, which spends most of its time not being used.) This is part one.

Part two: Heat engines have a surprisingly low maximum theoretical efficiency. The endoreversible heat engine efficiency equation is thus: (units are absolute degrees, Kelvin or Rankine)

The problem is that the Earth just isn't cold enough. Room temperature is 300 Kelvin! You're not going to want T_h to go much above 830K, or else you'll be producing nitrogen oxides in the exhaust. This gives a final endoreversible efficiency of 0.40. That's the maximum thermodynamic efficiency, and there ain't no way to beat thermodynamics.

You can bend the rules a little, though. It's impossible to extract any more mechanical work from the waste heat, but it's still heat, you can use it for things that don't need low-entropy heat sources. Like, say keeping a house warm, or heating water.

This is called Cogeneration, and depending on how you do it, you can get up to 90% total thermal efficiency. A popular home cogeneration system is the MicroCHP furnace, a natural gas turbine that provides hot water and forced-air heating from its waste heat outflow. It can also run as a backup generator during power outages, in which case it vents waste heat outside.

The synthesis of these ideas is obvious: Make a plug-in hybrid whose engine is a cogenerating furnace built around a multi-fuel gas turbine.

A brilliant idea! There are some problems.

1.) MicroCHP turbines are designed to run on natural gas only. The "multi-fuel" version would be a second generation product. The first gen would have problems: the natural gas fueling infrastructure in the United States is a lot more sparse than the liquid-fuels infrastructure.

2.) The turbine is going to want a lot of cooling. Does a trailer get enough airflow?

3.) How well does the turbine tolerate road vibration?

4.) There's a user design problem: for a cogenerating furnace to work well, you want it at the center of your house, where all the waste heat goes to keeping you warm. This essentially means that every user of this car has to have an insulated, attached garage, or else they'll be losing some efficiency.

5.) There's a user interface problem: You can drive out of the garage with the trailer attached easily enough, but you'll then have to back into the garage, trailer first, and then reattach all the connections. Manually. Every time you want to use it.

6.) There's a use-case problem: Every time you drive away with the turbine, you drive away with the house's sole source of heat and hot water. Fine with a single-occupancy home, might be a problem for a family.

7.) It is certain that in the near future, cripplingly heavy taxes will be applied to fossil-fueled vehicles. Will this count as one? Maybe?

8.) This idea isn't terribly original. There's a lot of prior art here. Getting a patent will be an uphill battle.

So, there. Eight reasons why I'm talking about this idea in a blog post, rather than a room of serious men in suits.

fun with spiders

2012-03-11T22:00:39-04:00

So I grepped my logs for everything that asks for robots.txt, and the results were interesting.

Firstly, there's a lot of spiders out there!

$ grep "06/Mar" spiders.txt | wc -l
69

When an article isn't trending, or I haven't posted lately, bbot.org does about 1200 hits and 300 uniques a day. Some spiders request robots.txt multiple times, but cloaked spiders don't request robots.txt at all, so it's a wash. This means that fully a fifth of my traffic is from machines.

This is odd, because in terms of actual traffic, Google is the only game in down.

The traditional social contract between search engines and site owners is that you let them download your site, and in return, they drive traffic to you. This contract is broken, and has been for years. Google provides 99.98% of search traffic.

Microsoft, Yahoo, Gigablast and Blekko maintain fabulously comprehensive databases, updated regularly, which nobody ever uses. (DuckDuckGo strips referrer headers from their outgoing traffic, so they might be super popular, I have no way to know) This doesn't even count the foreign-language search engines, like Baidu, Soso Naver, Daum, or Yandex, who I also never ever see traffic from, since my site's in English.

Now, I don't use robots.txt, but still. What a waste of time and money!

Spiders can be roughly grouped into three groups: Google, Everybody else, and spammers. Brandwatch, Sitexploration, Seoprofiler, Linkdex, and Metadatalabs are all "SEO tools", which want to charge you money to get reports on their vague guess at how many people link to you. Spotinfluence even wants you to sign in via Facebook to begin using their site, and if you're dumb enough to do that, you deserve whatever they do to your profile.

Some spiders don't take no for an answer.

208.115.113.85 - - [01/Mar/2012:14:09:51 -0500] "GET /robots.txt HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)"
208.115.111.69 - - [01/Mar/2012:15:37:17 -0500] "GET /robots.txt HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)"
208.115.113.85 - - [01/Mar/2012:18:24:34 -0500] "GET /robots.txt HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)"
208.115.111.69 - - [01/Mar/2012:19:56:54 -0500] "GET /robots.txt HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)"
208.115.113.85 - - [01/Mar/2012:22:02:14 -0500] "GET /robots.txt HTTP/1.1" 404 169 "-" "Mozilla/5.0 (compatible; Ezooms/1.0; ezooms.bot@gmail.com)"

Some really don't.

107.21.161.122 - - [06/Mar/2012:09:46:53 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
107.21.161.122 - - [06/Mar/2012:09:46:53 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
184.73.70.151 - - [06/Mar/2012:14:31:17 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
184.73.70.151 - - [06/Mar/2012:14:31:17 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
107.20.100.1 - - [06/Mar/2012:22:27:30 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
107.20.100.1 - - [06/Mar/2012:22:27:31 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
107.20.100.1 - - [06/Mar/2012:22:54:24 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"
107.20.100.1 - - [06/Mar/2012:22:54:25 -0500] "GET /robots.txt HTTP/1.0" 404 169 "-" "linkdex.com/v2.0"

I'm not sure what the rationale is for using such a short timeout is, or asking multiple times. Presumably if a robots.txt request returns a 404, and has been doing so for the last two years, one isn't going to appear five hours later. Google, on the other hand, only checks to see if I've changed my mind twice a day.

While I've got my logs open, I'd like to complain about this: (original domain replaced with .su)

91.229.175.130 - - [11/Mar/2012:19:52:39 -0400] "GET /clubwearguru.su/blog/clubwearguru.su/archives/clubwearguru.su/2009/clubwearguru.su/07/clubwearguru.su/index.htmlhxxp://bbot.org/clubwearguru.su/blog/clubwearguru.su/archives/clubwearguru.su/2009/clubwearguru.su/07/clubwearguru.su/index.html HTTP/1.0" 404 169 "-" "Mozilla/4.0 (compatible; ICS)"

This appears to request a valid page on my server, but with a domain inserted after every /. Does this actually work? Do people really automatically post their server logs online? The mind boggles.

If you liked this, you should donate! bbot.org is out of money, and is not long for this world otherwise.

donate or die 2012

2012-03-09T19:27:50-04:00

Well. So it's come to this. (Again.)

Last year I ran out of server money, and had to beg for funds. However, I'm no more employed than I back then, and I'm out of cash. Again.

Midnight and p4ch3c0 stepped up with incredibly generous donations, but in the intervening 14 months, they have ascended bodily into Heaven, to hang out with the other saints, and the Catholic church has canonized their Earthly remains. So I can't shake them down for any more money. I tried talking to the Pope, but I could feel the force of his disapproving frown over the telephone, so no dice there.

Bitcoin address: 1MjsXQNNXJNTbqis7yWVsShTiLa95aV6Mv

bbot.org has no ads. It is entirely reader-supported.

not to mention road salt's going to kill it after a decade

2012-03-06T20:27:23-04:00

So CarTalk recently featured a question from a guy who wanted a diesel car that would last 60 years, and 500,000 miles. (804,000 kilometres) The Tappet Brothers said he was crazy, that it was a dumb idea, but didn't actually answer the question.

Now, it is a dumb question, but I'd like to try a stab at it.

First of all, forget diesel. In fact, forget anything fueled by hydrocarbons. If you've glanced at the television in the last decade, you'd know that fossil fuels are a real bad long-term bet.

This means going electric, and (in 2012), paying a fairly steep price premium. Electric cars are also a mixture of good and bad news, from a maintenance standpoint.

The good: Many, many fewer moving parts. An internal combustion engine is an unholy pile of camshafts, crankshafts, pistons, gears, and fans; many of which run at high speeds, close tolerances, and very high temperatures. Maintenance is ongoing, and nontrivial.

In comparison, an induction motor has one moving part: the rotor. Over the course of 804,000 kilometres, you'll be going through a bunch of shaft bearings, but that's more or less it, for the motor. Plus, the extremely wide torque bands of electric motors mean that the gearboxes only need one or two gears, and if you use hub motors, and are willing to sacrifice high speed, you can run direct drive. This means the only consumable items on an electric car are the tires, the windshield wipers, and:

The bad: The battery.

We've been trying to figure out a good way to store electricity for the last century, and so far, haven't made a whole lot of progress. The best of the best, lithium-ion, is both heavier, and more expensive, per joule than gasoline. They're prone to bursting into extremely vigorous lithium-metal fires when abused, slowly discharge themselves when left alone, and have surprisingly short lifetimes when heavily used. (Say, in a car) Deep discharges also burn battery lifetime, say, if you bought an electric car that advertised a hundred kilometre range, and tried to actually drive a hundred kilometres.

Replacement costs are ball-punchingly steep: most of the cost of an electric car is in the battery pack, so replacing it is like buying most of a brand new car. If you drive it very, very gently, and never let it get below 50% charge, you'll probably be buying a new battery every 150,000 kilometres. At ~US$30,000 a pop, that adds up.

There's a degree of amortization here: over time, battery technology will get better, but it's anybody's guess as to how much better it will get.

In the article, Tom and Ray list off about a dozen features in today's cars that didn't exist 60 years ago. Power/ABS brakes, fuel injection, modern suspension technologies, etc etc. This is a bit disingenuous: there's very little room left for improvement, the gasoline car of 2012 is about as good as gasoline cars will ever be, except for one thing.

Autonomous cars.

The self driving car has been a staple of science fiction for the last, well, 60 years, but we're getting close. Real close. My wild-ass guess is that between DARPA and Google, the technology for driverless cars will be ready for prime time in five years.

The wildcard here is the legal side. We could have cars that drive themselves flawlessly, but without laws that let them operate on the street, they'll be useless.

Assuming we leap that hurdle, the big driver (ah ha ha) for autonomous car adoption will be insurance companies. And after driverless vehicles become common, we'll see laws that ban manual operation of vehicles anyplace where an out-of-control car could injure someone else.

So, no, buying a car today that would be useful for 60 years is not going to be easy.

the pinnacle of evolution

2012-02-24T21:43:44-04:00

(Attention conservation notice: Nothing said here is at all novel.)

So Maciej Cegłowski has updated his blog for the first time in four months. Upon encountering the novel task of "actually generating HTML", his gimcrack blogging software sprayed a couple random posts across his RSS feed, one of which was the venerable 2010 essay on scurvy in Antarctic exploration. Which, combined with some other things I've read recently, got me to thinking.

Vitamin C is just C₆H₈0₆. Carbon, hydrogen, oxygen. All the atoms are there in glucose, just in a slightly different pattern. You could drink sugar water all day and never get scurvy, if we could synthesize it ourselves.

Except we can't, because ten million years ago a primate species discovered that they ingest enough vitamin C in the natural environment to get by without making it themselves.

A regular sideshow on my other blog is finding terrible Tumblr themes, then picking apart their CSS. I've learned a lot about CSS in the process, in the "gaze upon this disaster, young one, and learn well its lessons" sense. But even the most incompetently written theme isn't as poorly designed as vasopressin, which, among other things, controls:

Water permeability of distal tubule and collecting duct cells in the kidney.
Increasing permeability of the inner medullary portion of the collecting duct to urea by regulating the cell surface expression of urea transporters.
Memory formation.
Peripheral vasoconstriction as a response to blood loss from serious injury.
Pair bonding.

The same hormone that controls your blood pressure also determines if you can form a relationship.

From "Arginine vasopressin receptor 1A":

Homozygosity in allele 334 of RS3 is associated in men (but not women) with problems with pair-bonding behavior, measured by traits such as partner bonding, perceived marital problems, marital status, as well as spousal perception of marital quality.[19]

In a study of 203 male and female university students, participants with short (308-325 bp) vs. long (327-342) versions of RS3 were less generous, as measured by lower scores on both money allocations in the dictator game, as well as by self-report with the Bardi-Schwartz Universalism and Benevolence Value-expressive Behavior Scales; although the precise functional significance of longer AVPR1A RS3 repeats is not known, they are associated with higher AVPR1A postmortem hippocampal mRNA levels.[5]

Who the fuck designed this? The answer is, of course, "nobody". The blind idiot god of evolution cares not at all for separation of concerns, or design elegance, it just cares about how many offspring are produced. For evolution, the person who died at the age of 29, with six children, and the person who lived for two hundred years and won six dozen Nobel prizes, but never had children, it considers the latter person to have failed.

It's even a mistake to think of evolution as an "entity" with "intent" or "purpose": evolution is the simple historical fact that the genes of the organisms which produce more offspring are more frequent in the general population. And so we have white blood cells that trigger diabetes when they don't have parasites to combat, or the thousand and one autoimmune diseases of an environment that is too clean: the blind flailing of an immune system fighting a battle that's already won.

The human body is the ultimate tangle of dependencies, nobody sat down with a clean sheet of paper and said, "Alright, I'll design this anthropomorphic replicator so that bacteria outnumber the endogenous cells 10 to 1." No, of course not! But bacteria were endemic in the ancestral environment, and so they colonized the human body, just as they've colonized every square millimetre on the entire planet.

It's almost amusing to watch the naturists try to spin this, as if it's a good thing that fully 30% of fecal mass is bacteria! You had to eat that food, yet it's being wasted on making bacteria. A prime example of local maxima. You could imagine a mutant human with stomach enzymes that could digest oligosaccharides itself, without needing bacteria-- but the bacteria are already there. There's no fitness advantage, all paths lead down from there, and evolution has no foresight. You need two unlikely mutations to occur in the same individual at the same time (oligosaccharidease and an immune response to whatever oligosaccharide bacteria we already use) to acquire a fitness advantage, and that coincidence will be vanishingly rare.

A pretty safe bet is that two hundred years from now, the idea of "vitamins" will be a quaint anachronism. Having to consume minerals is going to be with us for a while, barring really surprising breakthroughs in nuclear reactor miniaturization; but the need to periodically ingest acorbic acid is a bug, which will be patched sooner rather than later.

EDIT: There were about a dozen comments calling out how terrible this post looked on mobile browsers. Sorry, guys! Fixed.

using application/ecmascript on nginx

2012-02-16T09:12:36-04:00

So while I was browsing the Wikipedia article on Internet Media Types, (I am a very boring person) I noticed this:

application/ecmascript: ECMAScript/JavaScript; Defined in RFC 4329 (equivalent to application/javascript but with stricter processing rules)

Hey now, what's all this then? "Stricter processing rules?" I love stricter processing rules! Let's look at that RFC:

3.  Deployed Scripting Media Types and Compatibility

   Various unregistered media types have been used in an ad-hoc fashion
   to label and exchange programs written in ECMAScript and JavaScript.
   These include:

      +-----------------------------------------------------+
      | text/javascript          | text/ecmascript          |
      | text/javascript1.0       | text/javascript1.1       |
      | text/javascript1.2       | text/javascript1.3       |
      | text/javascript1.4       | text/javascript1.5       |
      | text/jscript             | text/livescript          |
      | text/x-javascript        | text/x-ecmascript        |
      | application/x-javascript | application/x-ecmascript |
      | application/javascript   | application/ecmascript   |
      +-----------------------------------------------------+

So, it looks like a typical web "standards" clusterfuck. I had been wondering why nginx served Javascript with the application/x-javascript mime-type, which was used for non-standard protocols, and now I know.

The only use of JavaScript on bbot.org, prettify.js, a Javascript-based code prettyprinting package, is actually a prime use for bleeding edge standards wankery. Code highlighting is pure progressive enhancement so the readers still using IE6 on their 2002-vintage PowerPC iMacs shouldn't miss anything.

(My prettify.js implementation is actually backported from my low-signal, high-noise adjunct blog, where I wrote a pair of posts on the topic.)

Enabling it on nginx is fairly easy. Just add a line to /etc/nginx/mime.types:

    application/ecmascript                es;

This will deliver any file with the .es extension as application/ecmascript, which should Just Work in any modern browser. Pow! Whammo! Easy!

However, nginx by default will serve it uncompressed, and with a fairly short cache lifetime. Let's change that.

First, add application/ecmascript to wherever you keep your gzip_type declarations. (In my case, conf.d/compression.conf ) Next, tell nginx to deliver it with the proper cache headers. In my case, I already had a location{} block inside my server{} virtual host block that did that for a bunch of filetypes, so I added es to it:

location ~* \.(?:ico|css|js|gif|jpe?g|png|es)$ {
  expires max;
  add_header Cache-Control public;
}

This matches against a bunch of extensions, (including both jpg and jpeg) and delivers them with the Cache-Control: public header, as well as the maximum allowable time for the Expires header, which for nginx is Thu, 31 Dec 2037 23:55:55 GMT. This is a bit silly, since any browser will request a new copy long, long before the year 2037, but hey, why the hell not. Here's what the complete headers look like now:

bbot@neon:~$ curl -I --compressed bbot.org/prettify.es
HTTP/1.1 200 OK
Server: nginx/1.1.8
Date: Thu, 16 Feb 2012 13:48:01 GMT
Content-Type: application/ecmascript
Last-Modified: Thu, 16 Feb 2012 12:53:10 GMT
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Cache-Control: public
Content-Encoding: gzip

the state of the reprap field

2012-02-02T04:11:14-04:00

I've been looking at RepRap derived 3D printers recently, and what I'm seeing is encouraging.

The basic idea of the RepRap project is to build a self REPlicating RAPid prototyping machine, in the vein of the von Neumann universal fabricator. This is, of course, very very hard to do; and the RepRap project is nowhere near achieving full closure, there are still a great many "vitamins", components needed for self replication that the printer can't make itself. (Exactly analogous to vitamins in the conventional sense: biomolecules required for life, which the body can't synthesize itself.)

I've been following RepRap for six years, and for the first five of those years, it hasn't been a very good bet.

A FDM 3D printer is exactly like a 2D inkjet printer, except with a Z axis, and with a hot glue gun instead of an ink printhead.

Those of you who are familiar with motion control hardware and plastics extrusion are currently feeling faint chills of foreboding, and indeed, this is a Hard Problem. The printer hot end needs to be able to extrude thousands of metres of filament without requiring maintenance, while still being made out of common materials, as well as being as light, (print speed is limited by how fast the printer can move the extruder around) and as cheap as possible. The X and Y axis have to be accurate, precise, and as cheap as possible. The print surface turns out to be another big problem: the RepRap machine can't use a heated build envelope, for power consumption reasons, (The plan is to eventually have 1 RepRap per 1 human person) so you need something that sticks very well to hot filament, but not at all to cold filament, and also doesn't require replacement after only being printed on six or seven times.

Subscribing to the RepRap blog for these last six years has been a front row seat to watching lots of very smart people beat their heads against a very hard problem. It's always been possible to make a RepRap, if you wanted to spend a great deal of money in return for a machine that was not enormously reliable.

It occurs to me that 3D printers have described a familiar arc of technological development, roughly paralleling that of general purpose computers. In The Beginning, there were commercial printers made by big names such as Stratasys, which resembled mainframe computers with their thrillingly large price tags, obligatory service contracts, price gouging on spare parts; and physically, being large steel boxes.

Then came the first few generations of RepRap, which were essentially the Altair 8800 to Stratasys' PDP-10. A 3D printer that fits on your desk, and doesn't cost $20,000! Wow! Amazing! Sure, you have to input programs by flipping toggles on the front panel, but it's a desktop computer. Would a mere mortal human want to buy one? Well, uh...

What we really need is an Apple 2.

I think I've found one. Well, one and a half.

The RepRapPro Huxley is a kit of the latest RepRap design, with the sixth generation electronics, the fancy new Bowden extruder, and really stellar print quality. The kit's $727, shipped, to North America. This is the easy option.

(Full disclosure: I'd buy the cheaper parts kit, without RP parts, since I live near Metrix Create Space, and could print them myself.)

Of course, I can't do anything the easy way.

The Quantum ORD bot (build log thread) is based on the Printrbot design, which has become thumpingly unpopular in the RepRap community for various boring reasons; and has been reverse-pirated as the Wallace model.

The problem with the mainstream RepRap model is that each axis has three components: the structural members, (Threaded rod) bearing surfaces, (Smooth steel drilling rod) and motion control elements. (Timing belt in the XY axes, more threaded rod in the Z axis) Since the structural members and the bearing surfaces are both static, you can just combine the two, and eliminate a lot of vitamins from the design.

So good so far. Except that the Printrbot is a bit of a toy: its design goal was to be as cheap as physically possible, which results in tradeoffs regarding frame stiffness, printing speed, build volume and mechanical reliability. (As Jamie Hyneman said, there is no free lunch with machines. Any money you save on mechanical quality, results in more time spent trying to keep the damn thing functional) Wallace is a better design, but it's barely a month old, and there are no commercial suppliers for it at all, and only one operational example of the design in the field.

Enter Makerslide.

(Ignore the ad copy on that page: Barton's a bit slow to update it. The Kickstarter's finished, you can buy it now, right now, at this very moment.)

Makerslide is just structural aluminum extrusion, as used in the venerable 5bears CNC mill, but with bearing surfaces molded into its surface. Which makes it a prime candidate to replace the drill rod in the Printrbot design, and get a vastly stiffer machine frame in the bargain; which also lets you scale up the build volume. With a R2C2 kit, it should be pretty easy to build a fast, reliable, FDM machine!

Oh wait, I don't have any money.

fun and games with unix pipes

2012-01-14T21:07:46-04:00

So Atomic's started a new thing. The first post is interesting, however, probably not in the way she intended.

It consists of an image thumbnail named tumblr_lxr0pclKpO1rn6clco1_500.gif, which links to the larger version, tumblr_lxr0pclKpO1rn6clco1_1280.gif. _500.gif is odd in several ways. For one, it's actually a JPEG, delivered with the image/jpeg mime-type. Secondly, it's huge, weighing in at 1,369 kilobytes... for a 500x346 pixel thumbnail. The original GIF is only 147 kilobytes, which makes the thumbnail nine and a half times larger than the full size file.

We've been down this road before. Let's take a look at the file.

exiftool -htmlFormat -v tumblr_lxr0pclKpO1rn6clco1_500.gif > report.html

If you look at that report, you'll see that the first 57,324 bytes are a perfectly normal quality 92 JPEG file, of an entirely sane size for a 500x346 image. And then there's 1,344,572 bytes of "unknown trailer", which starts with 0xffd9, the JPEG magic number. Let's do a quick bgrep...

bbot@neon:~$ bgrep ffd9 tumblr_lxr0pclKpO1rn6clco1_500.gif 
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0000dfea
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0001c111
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0002a300
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000385b0
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0004690c
tumblr_lxr0pclKpO1rn6clco1_500.gif: 00054d19
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0006318d
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000716aa
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0007fc70
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0008e2fe
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0009ca24
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000ab212
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000b9a00
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000c8126
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000d67b4
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000e4d7a
tumblr_lxr0pclKpO1rn6clco1_500.gif: 000f3297
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0010170b
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0010fb18
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0011de74
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0012c124
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0013a313
tumblr_lxr0pclKpO1rn6clco1_500.gif: 0014843a
tumblr_lxr0pclKpO1rn6clco1_500.gif: 00156426

Huh. 24 instances. 24 * 57 kilobytes = 1368, which is about how big our file is. How many frames are there in the original animation?

bbot@neon:~$ identify tumblr_lxr0pclKpO1rn6clco1_1280.gif | wc -l
24

Somehow, when producing the 500 pixel thumbnail, Tumblr managed to produce a thumbnail for each individual animation frame, then concatenated all of them.

Wow.

Whoops.

How did they do this? Well, I'm guessing it was a pipe.

One of ssh's many, many party tricks is providing a transparent unix pipe between two machines. Presumably Tumblr has a front-end machine that accepts uploads from users, scales it down with Imagemagick, then transfers it to Amazon S3. Here's a one-liner that replicates the bug:

$ convert -resize 500 input.gif jpg:- | ssh user@server.example.com "dd of=output.gif"

It's less obvious why this command is being executed. Additionally, while it replicates the bug, it doesn't produce the exact same file, it's about 141 kilobytes smaller.

One possible reason is that Imagemagick chokes on the original file, becoming extremely confused when you ask it to scale the overlay frames. Given this command, which should Just Work:

convert -resize 500 -layers optimize tumblr_lxr0pclKpO1rn6clco1_1280.gif 500.gif

Produces this:

Which is both extravagantly broken, and ten times larger than the original, larger in image dimensions, file. So Tumblr might have added a step in their asset pipeline to normalize certain GIF animations that Imagemagick chokes on.

(There might be a more graceful way to do this than converting it to a Motion PNG. If there is, tell me.)

convert input.gif mng:- | convert -resize 500 -layers optimize - output.gif

As you can see, this actually works, though the "thumbnail" is still twice the size of the original file.

Now, (putting ourselves in the shoes of the nameless sysadmin who was doing this) let's add the next step, where we actually upload the file to the remote server. Except that, whoops! We were hacking on the JPEG thumbnail code earlier, and we accidentally tell Imagemagick to send the image data as JPEG.

convert input.gif mng:- | convert -resize 500 - jpg:- | ssh user@server.example.com "dd of=output.gif"

And so, we end up with this ridiculous situation where the thumbnail is nine times bigger than the original file. I guess the moral of the story is to always check to make sure that something which is supposed to make files smaller, actually makes files smaller.

(Previously.)

when "pretty secure" isn't secure enough

2012-01-08T14:58:11-04:00

"Richard Stallman Was Right All Along"

"As a member of the Walkman generation, I have made peace with the fact that I will require a hearing aid long before I die, and of course, it won't be a hearing aid, it will be a computer I put in my body," Doctorow explains, "So when I get into a car - a computer I put my body into - with my hearing aid - a computer I put inside my body - I want to know that these technologies are not designed to keep secrets from me, and to prevent me from terminating processes on them that work against my interests."

Something I've been thinking about off and on for the last seven years or so, is what the security model for an em would look like.

Background info, for non-transhumanists: "Em" is a short, pithy word coined by Robin Hanson to refer to a person running on a computer. The basic idea behind Whole Brain Emulation is to scan a human brain with an electron microscope, then make a model of all the scanned atoms, and run that model in a physics simulator, which will run all the chemical interactions between neurons like it was a physical brain. This model will have all the memories of the person that was scanned, but has all the advantages of software: functional immortality, easy copying, can be run millions of times faster than real time...

The problem arises when you start to think about what kind of computer you're going to run this simulation on. It must be completely, flawlessly, secure. It absolutely cannot be hacked, because once you lose control of that computer, that's the ballgame. A copy of your brain-state is you. It's got all your memories, knows all your passwords.

That's bad. It gets worse: a brain-state is software, it can't "die" in the organic sense of the word. You could torture it to death, over and over, for a thousand years; if you felt like it. "They populate the simulation spaces of its mind, exploring all the possible alternative endings to their life."

So it's pretty clear that the operating system for a em is going to have be very special indeed. Quebes isn't paranoid enough. OpenBSD isn't paranoid enough. seL4 isn't paranoid enough. You will need a degree of paranoia hitherto unseen outside of nuclear weapons safety protocols and space shuttle flight control systems. Multiple, concentric, airgapped systems. ASICs that refuse to export their contents. Physical safety interlocks. Power draw monitoring. (Here being used in a somewhat unusual way: monitoring the power draw of a secure processor to verify that it hasn't been compromised) Provably secure code. Self-destruct charges!

Some of the sting of "killing yourself rather than be captured by the enemy" is taken out by having a couple dozen copies as backup, however.

This is a bar set amazingly, impossibly high; and it goes absolutely without saying that no general-purpose commercial OS clears it. However, many of the freedom-destroying technologies cut both ways. The Xbox 360, which has been out for six years now, uses code signing to enforce a closed platform. Downside: no third-party software, at all. Upside: there has never been a virus on the 360. (apt-get uses a weak form of code signing, and to the best of my knowledge, has never distributed a virus either)

The Trusted Platform Module can be used to build a computer which you can only install Windows on, but can also be used by Linux to protect against certain attacks.

This blog post doesn't really have a point, I just wanted to talk about some stuff. Sorry.

I'm certainly not saying that there's some kind of tradeoff between open-source and security. That would just be utter, blithering nonsense. I guess if there's any point here that I'm flailing in the direction of, it's that there are certain dual-use technologies, which are in danger of being misused by people looking to make money at the expense of the users; also known as the Facebook strategy.

table of the day

2011-11-17T19:02:58-04:00

I've seen a lot of neat tables in my day, but this one is really something else.

(From "Are Black Hole Starships Possible?", 2009)

It's not every day you learn that a one-attometre black hole would mass 673,000 tonnes, and radiate 129 petawatts of Hawking radiation. Some of that's in fairly harmless neutrinos, but the 15.7 gigaelectronvolt (GeV) gamma rays most decidedly ain't. (The gamma radiation coming off of a mass of Cobalt-60, (which is excitingly radioactive) by comparison, is a mere 1.33 MeV, 11,804 times less energetic. Attometre-gauge black holes pack a punch.)

The paper makes a pretty good case that using a microscopic black hole as a starship drive is at least physically possible, though there's a whole host of amusing practical problems that should be of any interest to the aspiring megaproject engineer with a couple state vector backups safely stored behind a kilometre of lead shielding.

Firstly is the problem of making them. Apparently Messrs. Crane and Westmoreland are the first people to seriously consider how to generate an artificial black hole, (!) and they conclude that the most practical method (!!) is "by firing a huge number of gamma rays from a spherically converging laser." (!!!)

One can easily imagine just how huge this would have to be, of course, since you're aiming to get the energy density of a couple cubic attometres high enough to spontaneously generate an object that masses 673,000 tonnes.

Once you've built your absolutely gigantic gamma ray laser array, and accompanying solar panel satellite well within the orbit of Mercury, you get to the fun part of calibrating the thing.

The best case scenario is that you generate a fairly large black hole, radiating at a sedate 130 petawatts or so. But if you don't get the power density high enough, then you might end up with a smaller black hole. The smaller the black hole, the more energy it radiates, and the faster it evaporates. At .9 attometres, it radiates 160 petawatts. At .6, 367 petawatts. At .3, 1527. At .16, 5519 petawatts and a lifetime measured in days! It's a short and steep slope to kaboomville. You can see here that a misaligned laser array is mostly a big machine for producing gigantic explosions.

The authors helpfully point out that if you're worried about the radiation flux affecting the Earth, you can just move evaporating black holes to the other side of the Sun. Which reminds me of a famous maxim: if you're using a star as radiation shielding, then you're having a fun time.

Then there's the problems of how to use something that mostly shines in the gamma ray spectrum as a propulsion device, and how to postpone the inevitable kaboom-date. You wouldn't think this would be a problem, since the popular conception of a black hole starts and ends with "it eats things", but take another look at that table. The attometre hole loses 1.43 kilograms a second to Hawking radiation. How are you going to cram 1.43 kilograms of mass into a point 2 attometres across?

The authors, who I absolutely cannot fault in the "imagination" or "audacity" departments, conclude that "this point must remain as a challenge for the future."