http://xkcd.com/661/

I've written today's blog post on paper. I'm on a train. Will update tomorrow!

Posted via LiveJournal.app.

Stuffing flavours

http://www.antipope.org/charlie/blog-static/2009/11/still_on_the_road_sort-of.html

I'm back home today and tomorrow, but off again on Thursday to Novacon 39 in Nottingham. Oslo was about as cold as Edinburgh, and about as dark; although a good time was had by all, all this rushing around in the dark is leaving me somewhat tired, and even a portable battery-powered daylight lamp for dealing with SAD (which has begun hitting me earlier and harder with each passing year since I turned 40) isn't helping much. (No surprise, if you bear in mind that I live 50 miles or so north of Moscow, some way north of every significant city in North America except Anchorage).

In the meantime, I have little to say except that I'm still thinking about the long haul in extra-planetary travel. Running a biosphere (as the past couple of discussions suggest) looks to be a lot harder than most people imagine — we don't even know where all the critical paths lie, and the longer it has to operate the more complex it gets (with failure modes that mostly appear to be ghastly variations on dying painfully and slowly of exotic trace element and micronutrient deficiency diseases). But there's another question that occurs to me. What are the other problems with building and running a biosphere in space?

Here's one: waste heat dissipation.

Vacuum is, as has been noted in the past, a good insulator. At the same time, it looks likely that any long-term human space habitat is going to need shielding from high-energy cosmic radiation (which is probably going to be physical, rather than electromagnetic, given the multi-GeV energy spectrum of the radiation in question). And for long-duration habitability, biospheres are going to need to be complex, multiply-redundant, and to include pathways to recycling micronutrients and exotica (not just for cycling carbon dioxide and water back into oxygen and glucose).

Approximating a space-based biosphere to a sphere would seem sensible — you can maximize the inhabitable volume per unit of external surface area, and the mass of the radiation shielding goes up in proportion to the external surface, not the interior. But radiation shielding works in both directions: biospheres take short-frequency light and down-convert it into long-wavelength thermal energy (the second law of thermodynamics is in play, here). Don't underestimate the amount of heat we need to dump. Per kilogram, mammalian muscle tissue ("us") puts out more watts of waste heat than an equivalent mass of the sun generates through fusion reactions! The waste heat a biosphere produces ought to be proportional to the mass of metabolizing organisms; and that is going to scale with the volume of the biosphere.

So, while it might make sense to make our spherical biosphere as voluminous as possible (to make best use of the dead mass we're hauling around as shielding), it's going to need radiators to dump the waste heat into space (background temperature: 2.725 degrees Kelvin). Their area is going to go up in proportion to the volume of the biosphere, not its external surface area. And they're not going to be a useful contributory part of the biosphere — they have to be outside the cosmic radiation shielding.

What other gotchas associated with the mechanical supports for an in-space biosphere can we expect to run into? (NB: I'm deliberately ignoring propulsion, political/profit motivation, and crew. If you want to talk about the requirements of running a biosphere, that's the previous topic.)

Rae and Adam invited us and Fluffy for dinner on Saturday to say thankyou to Mike and Fluffy for being bridesmaids. So we got the train to Cardiff arriving late Saturday afternoon with just time to take the dog for a muddy 45 minutes walk before it got dark. Dinner was lovely, with good company and much playing of estimation whist and then hearts after dinner. On Sunday we got up and out of the house about 10:30 and took the dog for another much longer walk, about 2.5 hours with me on the lead for much of the time. I'm still surprised such a small dog is so strong, and so hard to wear out! We ended up with a nice walk along the cliffs though, and Mike and Monster made it down to the beach, although it was a bit too muddy for the rest of us to attempt. We finished off the weekend with a cheap and very plentiful lunch in the pub, and a lovely pint of Brains Dark, before Adam dropped us at the station.

Having gone all that way it seemed like a good idea to take a couple of days off work and go visit Mike's parents too. So we got a train to Newport, and the bus to Chepstow and a lift home from there to their house, for a lovely curry for dinner and much amusement for me with Gina's Wii Fit Plus: I've already put a copy on my amazon wishlist but Mike now tells me I may need to remove it again :) After dinner Evan dropped us at Phil's house for a pleasant evening of gossip and Rock Band.

On Monday we got up late and headed out after breakfast at nearly 12 for a nice little bike ride. 23.1 miles and 2100ft of climbing (and descending again!) in around three and a half hours rather completely wore me out, especially after all the walking the previous days. So we slumped on the sofa for the rest of the afternoon before trying to take Evan and Gina out for dinner. But despite us saying it could be a late birthday present to them they still insisted on paying for their half!

It was lovely to see them anyway, and we had a nice time, and have spent today travelling home again without having to worry about anything more disruptive to the rail network than a cow on the line at Roydon leading to a 15 minute delay. Tired now!

ACPI handles this case by providing a set of general purpose events (GPEs). The implementation of these is fairly straightforward - an ACPI table points at a defined system resource (typically an area of system io space, though in principle it could be something like mmio instead), and when the hardware fires an ACPI interrupt the kernel looks at this region to see which GPEs are flagged. Then things get more interesting.

The majority of GPEs are implemented in the ACPI tables via methods with names like _Lxx or _Exx. The xx is the number of the GPE in hex, while the leading _L or _E indicates whether the GPE is level- or edge-triggered. If an ACPI interrupt is fired and GPE 0x1D is flagged as being the source of the interrupt, the ACPI interpreter will then look for an _L1D or _E1D method. Upon finding one, it'll execute it. What this method does is entirely up to the firmware - on most HP laptops, GPE 0x1D is hooked up to the lid switch[1] and so executing it will send a notification to the OS that the lid switch has changed state. The OS will then evaluate the state of the lid switch (generally by making another ACPI query) and send the event up to userspace.

How does the lid end up triggering GPE 0x1D? Things get pretty hardware specific at this point. Intel motherboard chipsets have a set of general purpose io (GPIO) lines that can, for the most part[2], be used by the system vendor for anything they want. For a lid switch, one of these lines is hooked to the switch and the BIOS configures the GPIO as an input. Pressing the switch will cause the GPIO line to become active. The GPIO lines are mapped to GPEs in a 1:1 manner, though with an offset of 16 - ie, GPIO 0xd will map to GPE 0x1d. If GPIO 0xd becomes active, GPE 0x1d will be flagged and an ACPI interrupt sent. The ACPI code will then do something to quash the interrupts, such as inverting the polarity of the GPIO[3], as well as send the notification to the OS.

Why are the GPIOs offset by 16 relative to the GPEs? The lower 16 GPEs (again, talking about Intel hardware) have pre-defined purposes[4]. These range from things like "Critically low battery" to "PCIe hotplug event" down to "This device triggered a wakeup". And the latter is what I'm most interested in here.

Various pieces of modern hardware can be placed into power saving states when not in use. The problem with this is that the user experience of having to turn on hardware before you can use it is not a good one, so in order to make this the default behaviour we need the hardware to tell us that something happened that requires us to wake the hardware up.

There's something of a chicken and egg problem here, but thankfully most of the relevant modern hardware has out of band mechanisms to tell us about things going on. The PCI spec defines something called Power Management Events (PME), which are driven by an additional current that's supplied to the hardware even when it's otherwise turned off. On plug-in PCI Express cards, firing a PME generates an interrupt on the root bridge and a native driver can interpret that, but for legacy PCI devices and integrated chipset devices the notification has to come via ACPI.

The example I've been working on is USB. It's a good choice for various reasons - firstly, there's already support for detecting when the USB controller is idle. Secondly, modern USB host controllers have support for generating PMEs on device insertion, removal or (and this is important) remote wakeup. In other words, as long as the USB bus is idle we can power down the entire USB controller. If the OS tries to access a USB device, we'll power it back up. If the user unplugs or plugs a device, we'll power it back up. If a previously idle device suddenly responds to some external input, we'll power it back up. And it's all nicely invisible to the user.

How does this work? The controller retains a small amount of power even when nominally pwoered down. This is used to keep the detection circuitry alive. When it receives a wakeup event, it asserts the PME line. The chipset detects this and fires a GPE. The OS runs this GPE and receives a device notification on the ACPI representation of the USB controller, telling us to power it back up. We do so and process whatever woke us - if the bus then goes idle again, we can power down once more.

The astonishing thing is that this all works. The only problem we have is that it relies on the machine vendor to have provided the ACPI methods that are associated with the GPEs. If they haven't, we can't enable this functionality - even though the hardware is capable of generating the GPEs, we have no method to execute to let us know which device has to be woken up. The GPE is never answered, we never acknowledge the PME and the hardware keeps on screaming for attention without getting any. And, more to the point, it never gets powered up and your mouse doesn't work.

There's a pretty gross hack to deal with this. In general, we know what the GPE to device mappings are - they're pretty static across Intel chipsets, and while AMD ones can be programmed differently by the BIOS we can read that information back and set up a mapping ourselves. This trick also comes in handy when some vendors (like, say, Dell) manage to implement one of the GPE events wrongly. Everything looks like it should work, but the method never sends a notification because it's buggy. In that case we can unregister the existing method and implement our own instead.

This code isn't upstream yet, but patches have been posted to the linux-acpi mailing list and with luck it'll be there in the 2.6.33 timeframe. My tests suggest about 0.2W saving per machine, which isn't going to save all that many polar bears but seems worth it anyway.

[1] _L1D = lid. Sigh.

[2] There's a few that are reserved for specific purposes

[3] So where before it had to be high to be active, it now has to be low to be active - this means that it'll now trigger on the switch being opened rather than closed, so you'll get another event when you open the lid again.

[4] You can find a list in the documentation for the appropriate ICH chip - the relevant section is "GPE0_STS" under the LPC interface chapter.

http://ai731.wordpress.com/2009/11/09/what-the-books-do-not-tell-you-about-killing-chickens/

http://ai731.wordpress.com/?p=813

by t!

When you raise chickens for meat, the logical endpoint of the raising is, of course, the slaughtering and butchering. And you have two choices about how this will be done: (A) by you, or (B) by someone else. We have decided to kill our chickens ourselves, and the several books we own which describe raising chickens all assume that this is what the reader will be doing. So far, so good.

However, the authors of these books have been raising chickens for quite some time. They enjoy it, they are good at it, and their books are designed to make chicken raising seem both fun and easy enough for anyone to do. The same goes for the slaughtering. It is easy enough, but there are a handful of tiny things that came up which I think deserve a mention, and these books did not quite warn us about.

- We use the broomstick method. What this is, is you lay the head of the chicken on a flat rock, place a broom handle across the back of its skull, place your feet on the handle, one on each side of the head, and yank up on the chicken’s legs. This breaks the chicken’s neck instantly, killing it. If you do it right. If you don’t, you will just damage the chicken horribly, probably paralysing it, but it will still be alive and frightened. Then you will have to pick up the injured terrified animal and kill it a second time. The key word here is to be *decisive.* Kill the chicken, with certainty, on the first try. This isn’t cruel; in fact *failing* is cruel.

- Also, some indication of how hard you should pull on the legs would be nice. If you pull too hard, the head stays behind.

- If you can keep the chicken’s head on when you kill it, afterward while you’re butchering you don’t have to worry about the gizzard spilling its contents out the top of the neck.

- You’ve heard that chickens flap around after they’re dead; everybody hears this. But it needs to be stressed: Chickens really *really* flap around. A lot. Enough such that we were glad the legs were tied so the corpse couldn’t run off down the road.

- The books play down how difficult it is for a caring human being to kill a chicken. One expects that the authors have become used to it, or that they don’t want the readers to think they can’t do it, which is all fair enough. But there should be some warning about the eyes. Once the chicken is dead, do *not* dwell on its eyes.

- Also the books do not warn you about the *feel* of that first chicken. You catch him, pick him up, and hold him steady, ready for the end. Since you rarely get this close to a chicken, you look him over. You’ve done well as a homesteader; he’s a good-looking animal. His chest is warm. You can feel it moving in and out as he breathes. He feels just like a kitty. You want to stroke his belly. Hang on – this is *not* the proper mood for poultricide! You’ll need a few sharp moments to rearrange your perspective and remember that this creature is food. It’s not too difficult to do, but I would have preferred it if I’d been prepared for that moment.

- If you read about killing chickens, you will be told that holding a chicken upside-down by its legs will cause the blood to rush to the chicken’s head, knocking it unconscious and making things easier on you and the chicken. Everybody agrees this will happen. Nobody will tell you how much time it takes for this marvelous passing out to occur. We’ve suspended the chicken and waited patiently; out of 11 chickens not one has ever passed out. But each of us has had a chicken try to escape by bending itself upward and pecking our hands.

- When you are cutting the legs off a chicken, the blade presses into its tendons. This causes the toes to curl. Therefore, when you cut into a chicken’s leg, the dead claws will grab your finger. This is rather startling the first time it happens. The second time, it’s still pretty creepy. I don’t know about the third time. I’ve changed the way I hold the leg.

- You hang chickens upside-down with their carotids cut (or heads missing, depending on how you killed them), to allow the blood to drain out of their bodies. This is better for the meat, and means less mess during innards removal and other butchering. The books all recommend you hang the chicken upside-down for a half hour, but they don’t tell you how much blood should drain out. We had one chicken that looked like it had clotted after two minutes, there was so little blood. But it did not bleed during the butchering. Our last chicken dumped a lot of blood into the pail for its half hour, and then bled some more in our garage, and then bled all over the counter during the butchering. Maybe the books don’t tell you how much blood is normal because it always varies? Perhaps this last chicken bled so much because it was one-third heavier than most of our others. Or maybe it had been taking Aspirin.

- With practice, one gets better at catching chickens. However, it does not get easier. The first ones you catch are the small and slow ones – the losers. The later ones are faster and more clever, plus there are fewer bodies remaining to get in their way when you chase after them. We were down to our last three roosters: The alpha, the second biggest, and the smallest. We decided, naturally, that the smallest should be killed, so that should anything happen to the alpha his replacement would still be a large bird. Well, it turned out the smallest one was also the fastest ever. After five minutes – a very long time when you’re trying to catch one specific chicken and all around you the other dozen are running flapping and shrieking – we gave up on him, and nabbed the second largest. He was *much* slower. Darwin has spoken; the one best able to avoid predators (or farmers) has prevailed.

We call him Speedy.

Episode 5

Characters

Brussel sprouts???

http://xkcd.com/660/

These states were universally weak because they lacked both legitimacy and money. Legitimacy was the biggest problem because even those states that did or could have money, such as the mining states, were also weak. Loyalty to the state is not an internalised feeling in today's Africa... Internally states are seen as cows to be milked. But because there is little milk and the cow can go dry at any time, it would perhaps be better to say that the state is a cow to be bled quickly before it slips into somebody else's hands. The state is an asset for the group in power, but that asset is fragile, there are no commonly accepted rules for future devolution of power, and things have to be grabbed while they last... The state is always somebody's state, never the State in the legal abstract form beloved of Western constitutional law. It is the Museveni dictatorship for the Acholi [Uganda], the Arab state for th southern Sudanese, the mestiço state for UNITA [Angola], or the Tutsi state for the Hutu [Rwanda]. When tribes are not the main problem, pseudo-tribes or other groupings will do.

There's another spam bot heuristic which is the exact complement to the one described in my prevous post. The idea is to keep rack of how many different HELO domains an SMTP client uses.

  defer
    message   = Probable spam bot HELO varies between $sender_rate domains
    # whitelist checks go here
    ratelimit = 2.2 / 1w / per_conn / strict \
      / unique=$sender_helo_name / $sender_host_address

This is mostly the same as the code in my previous post, but the lookup key is the client's IP address, and we only increase the measured rate if the client uses a different unique HELO domain.

This check also works very well at detecting spam bots. When testing it I noticed that one particular bot likes to use a HELO domain consisting entirely of random upper-case letters, and it only talks to one of our servers with the lowest IP address. So I added a specific (cheaper) check to deal with it. This causes the bot to go away, and legitimate senders will retry with a different server.

  defer
    message   = Probable spam bot HELO - please try another server
    condition = ${if and{{ eq{$primary_hostname}{ppsw-0.csi.cam.ac.uk} } \
                              { match{$sender_helo_name}{^[A-Z]+\$} }} }

There is a small risk of false positives with the variable HELO domain test. Some outgoing mail server clusters are behind a NAT, so we see HELO domains from multiple servers coming from the same IP address. I also found a number of false positives for the popular HELO domain check (most prominently rediffmail.com and easyjet.com). The way I'm dealing with them (which I hope will work in the long term) is as follows.

For the popular HELO domain check described in my previous post, I maintain a lookup table of legitimate HELO domains that trigger the check. The following replaces the hard-coded check for localhost.localdomain that appears in my previous entry.

    condition = ${if !match_domain{$sender_helo_name}{cdb;DB/helo_ok.cdb} }

As well as allowing through clients whose HELO domain can be verified, I now also check dnswl.org for well-known legitimate senders, and I maintain a table of sending hosts that slip through the other checks.

  ! verify   = helo
  ! hosts    = +helo_ok
  ! dnslists = list.dnswl.org

To avoid problems with false positives, my anti-spam-bot checks return a temporary error code ("defer" in Exim-speak instead of "deny"). I then have a nightly audit script which looks for hosts that appear to be repeatedly retrying a messages and which should be added to my whitelist tables. It might be possible to automate this table maintenance, again using the ratelimit feature, but I expect that will require a bit more experience to determine the right thresholds.

crazyscot's recent LJ post about a factor-of-20 speedup of some code reminds me that I've never written down in here the story of my first summer job, despite it being a standard anecdote I use in real life when I get into those ‘the worst code I've ever encountered’ geek war-story conversations.

( some of the worst code I've ever encountered, and how I too sped it up by a factor of twenty )

The boss took one look at the speed test, and shook his head. ‘We can't ship that,’ he said, ‘it's far too embarrassing. We'll have to deliberately slow it back down again, and ship lots of incremental speed upgrades.’

I laughed.

He turned out not to be joking.

If you are writing about a fair-haired woman, which is correct:

Can a thing or person which is ovate also be willowy?