About: Bring on the open source, open data, linked data, distributed and sublime future.
Bookmarks:
It's Man Vs. Machine In 'Digital Apollo' : NPR
Talk of the Nation: David Mindell, a professor of history and engineering, talks about the politics, the pilots and the technology involved in space travel.
Interchange and the Price of Gas
With all the attention being paid to the soaring cost of gasoline, there's one price component that could easily be lowered that hasn't gotten a lot of attention: interchange. Americans pay about 10 cents/gallon or $2/tank (20 gallon) in interchange fees. Compare this with the estimated benefit of drilling in ANWAR--3.5 cents per gallon by 2027. Tremendous political energy that has been spent over drilling in ANWAR. If we're really interested in reducing gasoline prices, then reforming the interchange fee system presents an option of immediate savings that would far outstrip ANWAR. Of course, the maximum savings would be less than from a federal gas tax (18.4 cents/gallon), but a gas tax holiday isn't permanent. (I'm putting aside the question of whether we should want pricing that encourages fossil fuel consumption.)
Fortunately, the good folks at Visa are looking out for the American consumer. And out of concern for American drivers, Visa has adjusted its interchange rate schedule. Unfortunately, there's more than meets the eye to Visa's apparent benevolence and desire to "Help Ease Pain at the Pump." The devil, of course, like so many things in the card industry, is in the details.
When you go to the gas station and you use a Visa card, the gas station will pay its acquirer bank a merchant discount fee that consists of the interchange fee plus some thin profit margin for the acquirer. For simplicity's sake, let's just say that the merchant pays interchange and ignore the acquirer's margin.
So currently, if you fill up your tank and pay at either a service station or an automatic fuel dispenser with a Visa card, the interchange fee will be is a five or ten cent flat fee plus between 1.43% and 2.10% of the purchase price (depending on rewards level). So on a $50 tank of gas, you're paying your credit card issuer that's between $.80 and $1.15. I'm going to use the $1.15 for illustrative purposes.
Let's say you can buy 12 gallons of gas for $50, so gas is $4.17/gallon (close to the national average). If you weren't paying the interchange fee, you'd be getting 12 gallons for $48.85. That means gas would be $4.07/gallon. In other words, you're paying 10 cents a gallon to your credit card issuer. And that's before any interest or late fees, etc. For smaller purchases, the credit card tax on gasoline gets higher because of the flat fee. And if the price of gas/gallon is higher, then interchange represents an even greater cost per gallon.
[For debit, Visa's interchange fee is .70% plus 17 cent flat fee, but debit card transactions at service stations often result in debit card holds--much large notional charges--that can limit the cardholder's available funds for a few days. I'm going to leave the debit card hold issue aside for now.]
So what has Visa done in response to the "Pain at the Pump"?
Visa instituted a new interchange fee for all gas stations of 1.5% 1.15% of transaction price plus 25 cents, regardless of the level of rewards on the card. Because of the increased flat fee, consumers making high dollar amount transactions will pay less, but consumers with small transactions will pay more. Where is the dividing line? It depends on whether you were using an exclusive Visa Signature Preferred Card (2.10% + 10 cents) or a mass market rewards card like Visa Signature or Traditional Rewards (both 1.65% + 10 cents) or a non-rewards card (1.50% + 5 cents). If you are wealthy enough to land a Visa Signature Preferred Card, this means the cost of interchange to the gas station (and thus ultimately to you) will be less on transactions over $15.79. If you have a regular rewards card, then the savings kick in at $30. And if you don't have a rewards card at all, then the new rates are actually more expensive for the station for all transactions under $57. [Correction 7.2.08]
Does this new structure actually represent a lowering of interchange costs for gas stations? It depends on the card mix and the purchase prices. If everyone in town drives a Hummer and has a Visa Signature Preferred Card (Greenwich?), then this is a great program. But if most people have plain vanilla cards and aren't letting their tanks get bone dry, then that $57 threshold is pretty high; I rarely exceed $57 for a single gas purchase with my thirsty minivan. That'd mean that gas stations would be paying even more in interchange and the price to consumers would go up even more.
Surely Visa looked at card usage data and concluded that it would actually be more profitable to lower percentage fees while increasing the flat fee. Visa is a for-profit company, after all, and there's no tax write-off to helping consumers. So it is easy to see a scenario in which Visa gets the PR boost for trying to help consumers, while actually sticking it to them.
Curiously, the Visa move also undercuts Visa's litigation and lobbying position, that interchange is just an interbank fee. By announcing its "lowering" of interchange rates as a move to help consumers, Visa implicitly acknowledged that interchange contributes to consumer costs. (The best empirical evidence that interchange is passed on to consumers also comes from the gas station industry.) Interchange is not just a Main Street vs. Wall Street issue. It is also a consumer issue.
All of this points at the need to think about ways of reforming the interchange system. One possibility is that it will be done through the courts. Another possibility is that it will be done legislatively. Interchange week will continue with a post about the Credit Card Fair Fee Act.
Greenhouse Gases: Where Do They Come From?
Shared by Luke Opperman
Beautiful graphic
The World Resources Institute has a geekalicious image (see page 15 of this pdf) that shows how human activities contribute to global warming. Click on the image below to get a legible, full-sized version.
The most interesting bit, to me, is the massive contribution of agriculture and land use -- the green and purple areas on the bottom left -- to global climate change. Worldwide, the net impacts of land use are far more significant than global transportation emissions.
But in the Northwest, the situation is reversed. At the moment, forests in this part of the world appear to be carbon sinks, and transportation is far and away the largest single source of climate warming emissions. So just because transportation isn't the biggest deal globally, it's still where state and regional policymakers should focus their attention.
Help us change the world - DONATE NOW!
(Posted by Clark Williams-Derry in Climate Change at 2:31 PM)
Wired Magazine’s Incoherent Truths
Shared by Luke Opperman
Ah, the comforting jolt of reading such articles offering intuitive (or cleverly counter-) lifestyle suggestions. But RealClimate reminds us once again that for today's confoundingly complex global issues, first shut up and [have someone] do the math.
Many of our tech-savvy friends — the kind of folks who nurse along the beowulf clusters our climate models run on — are scratching their heads over some cheeky shrieking that recently appeared in a WIRED magazine article on Rethinking What it Means to be Green . Crank up the A/C! Kill the Spotted Owl! Keep the SUV! What's all that supposed to be about?
Let's take air conditioning for starters. Basically WIRED took a look at the carbon footprint of New England heating vs. Arizona cooling and jumped to the conclusion that air conditioning was intrinsically more efficient than heating. To see where they were led astray let's consider a house sitting where you need to cool it by 20 degrees to be comfortable. The heat leaks into the house at a rate that is approximately proportional to this temperature difference, and the heat leaking in needs to be removed. Now, in order to move that heat from inside to outside, energy has to be expended. Given a fixed electric power usage (in watts), a better air conditioner can remove more heat per day than a worse one, but every air conditioner needs to expend some energy to move the heat. That's just thermodynamics.
Efficiency of air conditioners is measured by a SEER rating, which is the ratio of heat moved to the outside (in BTU/hr) to the electric power consumption (in Watts). A typical modern air conditioner has a SEER rating of 10, We can convert this into nicer units by converting BTU/hr into Watts, which means dividing the SEER rating by 3.413, which then gives us a Coefficient of Performance, in units of Watts of heat moved per Watt of electricity used. For the aforementioned efficiency, we move heat at a rate of 2.92 Watts if we expend 1 Watt of electric energy. An air conditioner is just a heat engine run in reverse: instead of making use of a temperature differential to use heat flow from hot to cold to do work, we expend mechanical work in order to move heat from a colder place to a hotter place. Thus, an efficient heat engine is an inefficient air conditioner. That's basically why the Coefficient of Performance gets smaller when the temperature difference between indoors and outdoors is greater — with bigger temperature difference heat engine cycles tend to get more efficient, which means that air conditioner cycles tend to get less efficient. That's also where the "S" in SEER comes from. It stands for "Seasonal," and reflects the fact that efficiency must be averaged over the range of actual temperature differentials experienced in a "typical" climate. Your mileage may vary.
This situation can be contrasted with heating. If that same house were in an environment that were too cold instead of too warm, so that it had to be kept 20 degrees warmer than the environment, then the amount of heat leaking out of the house each day would be about the same as the amount leaking into the house in the previous case. That heat loss needs to be replaced by burning fuel. Now, generating heat is the only thing that can be done with 100% efficiency. Old furnaces lose a lot of heat up the chimney, but modern sealed-combustion burners– the kind that can use PVC pipes instead of a chimney — lose virtually nothing. With a heat exchanger between the air intake and the exhaust, they could closely approach the ideal. But still, in this case we are generating heat rather than just moving it, so it takes 1 watt of heat power from fuel burning to make up 1 watt of heat loss. That would seem to make heating a factor of 2.92 less efficient than air conditioning.
But wait, the story doesn't stop there. First, there's the fact that air conditioning almost invariably runs off of electricity, and the increased electricity demand is a big source of the pressure to build more coal-fired power plants. A house can be heated by burning natural gas, and right there air conditioning becomes 1.8 times worse than heating, because natural gas emits only 55% of the carbon of coal, per unit of heat energy produced. And it gets even worse: Coal fired power plants are only 30% efficient at converting heat into electricity, on average, so there you get another factor of 3.3 in carbon emissions per unit of energy transferred between the house and its environment. Finally, figure in a typical electric line transmission loss of 7% and you get another factor 1.075. Put it all together with the energy efficiency of the air conditioner itself and air conditioning comes in at a whopping 2.19 times less efficient than heating. for a given amount of temperature difference between house and environment. That means that so far as carbon emissions go, heating a house to 70 degrees when the outside temperature is 40 degrees is like cooling the same house to 70 degrees when the outside temperature is 83.7 degrees.
And that's still not the end of the story. A house in need of air conditioning has other heat inputs besides the heat leaking in from outside, and all that extra heat needs to be gotten rid of as well. For example, heat is a waste-product of all energy use going on in the house. Four people produce 400W that needs to be gotten rid of, and then there's the heat from hot water, lighting, the TV, cooking and what have you — all the energy usage within the house, plus 100W of biological heat per person needs to be gotten rid of. On top of that, you've got direct radiative heating from the sun, both from the sunllight getting through windows and solar heating of the exterior surfaces of the house, some of which will leak in through the insulation. Energy must be expended to remove all this heat. In contrast, in the heating season waste heat is subtracted from the energy needed for home heating.
So, WIRED got the story egregiously wrong, and not just because they did the arithmetic wrong. In their rush to be cute, they didn't even make a half-baked attempt to do the arithmetic. But what if they had been right and air conditioning really were intrinsically more efficient than heating. Would that justify their conclusion that you can just "crank up the A/C?" without worry? No, of course not, because cranking up the A/C would still use additional energy and still lead to the emission of additional carbon. For the conclusion to be justified, it wouldn't be enough for A/C to be more efficient than heating; it would have to be so much more efficient that the incremental energy usage from cranking it up were trivial. WIRED didn't even try to make that case. If they had, they might have spotted their errors.
Is there any real conclusion that could have been drawn from more clear thinking about the heating vs. air conditioning issues danced around in the article? Yes, in fact. The conclusion is that it makes a lot of sense to build houses in places where the environment requires neither much heating nor much cooling. This is in fact why Los Angeles scores pretty well in carbon footprint per capita, despite all the driving (as noted recently in The Economist.). Another conclusion to be drawn from the carbon footprint of New England heating is that there are probably a lot of leaky homes up there heated by inefficient oil-fired furnaces. Fixing that situation represents a huge untapped virtual energy source.
What's more, for a magazine that purports to be written by and for tech geeks, WIRED missed the biggest and most interesting part of the story: the same intrinsic efficiences of heat pumps can be run in reverse to give you the same economies for home heating as you get for air conditioning. To do this effectively, you'd have to run the heat pump off of natural gas rather than electricity (or perhaps run it off of locally generated solar power or wind). You'd also have to deal with the fact that heat pumps become less efficient when working across large temperature gradients, but that's where geothermal heat storage systems come in, making use of the fact that the deep subsurface temperature remains near a nice 55F all year around. Now that would have been a nice story for a tech magazine to cover. And by the way, the decrease in efficiency of heat pumps as the temperature differential increases has another implication that WIRED missed: not only does global warming increase the basic demand for air conditioning, with all the attendant pressures on electricity demand, but it exacerbates the situation by decreasing the efficiency of the entire installed base of air conditioners.
Now about that spotted owl. This refers to a claim that industrial tree plantations take up carbon faster than old growth forests; Since spotted owls require the large trees found only in old-growth, the supposed implication is that if we want to soak up carbon we ought to damn the spotted owl and cut down all the old growth. WIRED really committed serial stupidities on this one. First of all, the article they cited in support of their claim was about carbon emissions from Canada's managed forests, not from old growth. Now, it's true that a rapidly growing young tree takes carbon out of the atmosphere more rapidly than a mature forest which more slowly transfers carbon to long term storage in soil. However, to figure out how much net carbon sequestration you get out of that young tree once it's chopped down, you need to figure what happens to it. Lots of trees wind up in paper, carboard boxes, shipping palettes and other things that rapidly sit around decomposing or get burned off (or worse, turn into methane in landfills). Even the part that turns into houses has a relatively short residence time before being oxidized. Anybody who has maintained an old Victorian house knows about the constant battle against rot, and the amount of wood that needs to be replaced even if (knock wood) the thing doesn't burn down or turn into a tear-down. So, WIRED is totally off the mark there, unless, to use the colorful language of my colleague Dave Archer, they can get trees to "drop diamonds instead of leaves."
Worse, they ignore the abundant literature indicating that old growth forests can be a net sink of carbon even in equilibrium, whereas the soil disturbance of clear cutting and industrial forestry can lead to large soil carbon releases. A classic article in the genre is "Effects on carbon storage of conversion of old-growth forests to young forests" (Harmon et al. Science 1990) . They state "Simulations of carbon storage suggest that conversion of old-growth forests to young fast-growing forests will not decrease atmospheric carbon dioxide (CO2) in general, as has been suggested recently.". For more recent work, take a look at what Leighty et al. (ECOSYSTEMS Volume: 9 Issue: 7 Pages: 1051-1065. 2006 ) have to say about the Tongass:.
- "The Tongass National Forest (Tongass) is the largest national forest and largest area of old-growth forest in the United States. Spatial geographic information system data for the Tongass were combined with forest inventory data to estimate and map total carbon stock in the Tongass; the result was 2.8 +/- 0.5 Pg C, or 8% of the total carbon in the forests of the conterminous USA and 0.25% of the carbon in global forest vegetation and soils. Cumulative net carbon loss from the Tongass due to management of the forest for the period 1900-95 was estimated at 6.4-17.2 Tg C. Using our spatially explicit data for carbon stock and net flux, we modeled the potential effect of five management regimes on future net carbon flux. Estimates of net carbon flux were sensitive to projections of the rate of carbon accumulation in second-growth forests and to the amount of carbon left in standing biomass after harvest. Projections of net carbon flux in the Tongass range from 0.33 Tg C annual sequestration to 2.3 Tg C annual emission for the period 1995-2095. For the period 1995-2195, net flux estimates range from 0.19 Tg C annual sequestration to 1.6 Tg C annual emission. If all timber harvesting in the Tongass were halted from 1995 to 2095, the economic value of the net carbon sequestered during the 100-year hiatus, assuming $20/Mg C, would be $4 to $7 million/y (1995 US dollars). If a prohibition on logging were extended to 2195, the annual economic value of the carbon sequestered would be largely unaffected ($3 to $6 million/y). The potential annual economic value of carbon sequestration with management maximizing carbon storage in the Tongass is comparable to revenue from annual timber sales historically authorized for the forest."
So, it looks like that old Spotted Owl and its kindred old-growth denizens are in fact sitting not just on a nest, but on a treasure trove of carbon credits worth potentially more than the timber harvest.
And should you keep that SUV? This blurb in fact contains some useful advice, buried amidst some fuzzy reasoning and published over a witless tag line stating that "pound for pound" a Prius takes more energy to manufacture than a Hummer. The apparent implication of that tag line is rebutted in the article itself, but why give the reader that as a 32-point type take-home point when the WIRED editors don't even themselves believe it's an important statistic? This factoid refers to the energy used in the nickel component of Prius batteries, but it's irrelevant because "pound for pound" doesn't count if your point is moving 4 people from point A to point B. What transport value do you get from transporting four people plus the weight of the Hummer? Now, the rest of the fuzziness in the logic is a bit more subtle. The author notes quite rightly that there is a very significant carbon emission from manufacturing a car, which is indeed more for a Prius (at least for the moment) than it is for comparable sized non-hybrids.. Thus, if you are faced with ditching your existing car (whatever it may be) and buying a Prius, you need to consider how much you drive per year and see how long it takes to "pay back" the carbon emission from manufacturing the Prius. So far so good. But this is more a statement about the transition to more efficient cars, and how to deal with mistakes of the past, rather than a statement about what is intrinsically desirable in the fleet. As far as carbon emissions go, we'd still be better off if everybody who needed a car were in a Prius, except maybe for people who drive very little per year — who should then be into shared hybrids via iGO or ZipCars, Maybe if you drive very little and live out in a rural area where there are not going to be any shared cars, getting a compact non-Hybrid might make sense. There must be at least a dozen or two people out there in that category, I guess.
The rest of the advice WIRED gives makes even less sense. They say that if you want to be green, you ought to buy a used Civic or something like that, not a Prius. That's because the used car already has the manufacturing carbon emissions "written down" (or, I guess at least the carbon guilt accrues to the original owner, not that the atmospheric radiative forcing is going to care much about that). However, this advice, sensible-sounding though it is — ignores the fact that to make that used car available to you, the original owner almost certainly had to buy something else, and probably that was a new car, or at least a newer one. So, for the scheme to work, you'd have to buy your used Civic from somebody who was giving up driving altogether. I no longer own a car myself, but I'm sorry I wasn't able to participate in a scheme like this; by the time I gave up our remaining car ten years ago, it was suitable only for the crusher, and in fact had to be towed there.
The real implication is that manufacturing costs count, so most people should buy a small, efficient hybrid and keep it until it runs into the ground. The implication is also that durability of cars counts for nearly as much as gas mileage, since an efficient car that needs to be replaced every five years isn't really all that efficient.
Along with all the nonsense is a certain amount of true (if by now commonplace) advice. Among this is the basic truth that urban living is inherently green, and if more people lived in cities (and if more cities were kept livable so people would want to move there). then per capita carbon emissions would go down. Even there, the Economist managed to be both more informative and more iconoclastic with its surprising analysis of the pattern of urbanism in Los Angeles. The other truism in WIRED is that nuclear power deserves a second look, and probably has an important role to play in a decarbonized energy future. Still, if you compare the cost of making all those chilly New England homes efficient with the total true cost of building more nuclear plants, well, let's just say I'm buying stock in argon-filled low-e window manufacturers rather than Areva, much as I like their track record on nuclear electricity.
Thoughts on DVCSs
Shared by Luke Opperman
Being a cautiously pro-mercurial user due to ignorance of most else, and hopelessly enamored with blurring data storage boundaries, I find much to concur with here.
I've been thinking about version control a lot lately. I just wanted to get some thoughts I've been having out there so people who know what they're talking about can shoot them down.
I'm going to structure this as a series of predictions, none of which I particularly believe are correct. Nevertheless, the format makes for an easy true-or-false binary judgement later on. The playing with format is also because I've been reading GEB, and I feel like trying a new format. So here goes:
1. Bazaar Will Never be a Serious Player
Bazaar, depending on your perspective, either takes the best of both Mercurial and Git, or the worst. I can sympathize with both views. On one hand, it is Python and pretty well cross-platform, and not the C-and-shell which caused so many portability issues for Git. It's also apparently supposed to be "getting there", speed-wise - although, the checkout of bzr trunk I have going on is certainly taking its time.
But bzr has at least one problem - and that is that it has broken repository-format compatability, at least once. This kept me from trying out Zed Shaw's projects for some time - the time investment to apt-get and then bzr branch is okay, but once I had to start worrying about versions, I gave up. Mercurial is working today.
And while problems can be forgiven, then need to be offset with something significantly new, and I don't see that with bzr. Mercurial, and Git to an even larger extent, are innovating in the DVCS space, while Bazaar is making a slower, less widely used reimplementation of all their features.
On a less-serious note, Bazaar also has another disadvantage: bzr is awkward to type compared to "git" and "hg". "hg" wins, as it's two keystrokes by different fingers - you can even alias gh to hg in your .bashrc and make it basically instantaneous. Git requires a "A-B-A" pattern, but with alternating hands; bzr requires A-B-A but on the same hand, with a further distance between the first and third keystrokes, and a pinky-keystroke required for z. But hey, whatever. Maybe it's not a major issue, but call me when a version control program named qzzqx storms the world, k?
Bazaar does have another big advantage, and that is Canonical. I can still see Bazaar usage increasingly greatly in a very specific and unlikely set of circumstances, among them Launchpad being open-sourced soon and 3rd-party hosting services using Launchpad taking off. But even if that were to happen, I'd be surprised if no one just wrote a Git or Mercurial backend for Launchpad's VCS features. But it could happen. It's just not likely.
I've finally got the bzr trunk checked out, and I do want to say that the code looks damn nice. I'd heard Mercurial's code pointed out to me as good Python code, but the ui-passing everywhere turned me off (if you've coded for the Mercurial APIs, you know what I'm talking about). Bazaar's source looks considerably cleaner, with sane style. It reminds me of Django's source. This is, of course, a 2-minute, mile-high overview, but that's what I see.
2. Mercurial is Worse (is Better)
I started recognizing Python as a better Blub than Lisp (I'll expand on that someday) when I learned that many Python "warts" - such as statement-less lambdas - were in fact conscious decisions. The Python developers looked at their choices, considered the arguments for more powerful lambdas, and decided against them. Python is as Python is because that's what the Python devs want it to be. There are certainly warts - the whole unicode/str thing in 2.x comes to mind - but some design decisions were made to trade power for clarity, and that's a fair trade.
With Mercurial, similar tradeoffs are apparent. Tags are implemented with a .hgtags file that simply maps a revision number to a name. I commented to a coworker how that seemed somewhat hacky, and his response was "what's wrong with it?" And he's right: that's all the tags really are; 1-to-1 mappings. A flat file is perfect for them, but my object-oriented mind objected to custom formats in a flat file. I mean, yuck! Shouldn't it at least be serialized somehow?
Of course, the flaw was with my dogmatic assumptions, and not with the implementation, which has worked just fine.
(I do have one beef with .hgtags and .hgignore files - if Mercurial keeps up that convention, there'll be too many .hgFOO files. Just stick them in .hg/, please! Not that I'm actually advocating this change - it'd be too complex and backwards-incompatible to be worth it, but if I had been involved 3 years ago, it's what I would have advocated.)
Likewise, Mercurial ignores directories and the cross-platform vagaries of versioning something that varies widely across operating systems and filesystems. It just versions files at a particular path instead, and creates directories on-the-fly as needed, as well as removing them when empty. This inspired the same WTH? reaction in me at first, but after more time has passed, the question has become, "why not?" A huge chunk of complexity and bugs was removed, and replaced with sane behavior that, in 90% of situations, is exactly what the programmer would have done anyway.
2.1. But Worse is Worse!
But these simplifying abstractions are not complete, and as such they do leak, and one way they do so is with renames. Mercurial handles renames as a remove-and-add. This leaks in a few ways - first, in 'hg status', it actually looks like an add and a remove, which still makes me have to think twice when looking at that situation. More importantly, though, it can inflate the repository size when moving large numbers of binary files, as a copy of the file's contents is stored at each path at which it appeared (in the internal repository format).
This is exacerbated by the fact that Mercurial repositories can never shrink. History cannot be (easily) rewritten. SVN made the same choice, and I think it's worth noting that after all their experience with this choice, they want to change that behavior. Couldn't we learn from their experience, and have partial-history and partial-tree cloning considered must-haves from the get-go?
The suggested solutions all tend to rely on what looks to my untrained eye like 'fooling' Mercurial itself by adding nonsense data to the repository, and then teaching Mercurial to look for these sentinel values and treat them specially. It'll probably work, and work well, in the true 'Worse is Better' sense - but it shouldn't be mistaken for built-in, semantic knowlege of partial or shallow checkouts by Mercurial itself.
I'm going to blatantly assume that this state of affairs is the result of further incompleteness in the simplifying abstractions that were chosen for Mercurial, but I'm really just guessing. It'd make sense though.
I don't know enough about Git to speak about what challenges its choice of abstractions cause. As you could probably have guessed by now, I'm going to anyway. I'll pretty much just make up stuff as I go along and pretend that actually researched it.
3. Git's Model Will Die of Packing
You know what bugs me about Postgres? Vacuum. There's really no other way to do append-only databases... but it still bugs me.
Still, Postgres gets a free pass because they are the database experts, not me, and if the database wants to have a daemon process running, I'm okay with letting them handle that as they best judge, especially since a daemon will need to be running to accept connections anyway.
Git doesn't have that situation. Git repositories need maintenance, and yet, aren't maintained unless the programmer does it. This is unfortunate. I only know of one other piece of software that gets away with this; I'm thinking of ZODB. But ZODB only needs to be maintained by a server admin, and only every few months. Git has to be maintained (maybe if I say "hand-held" it'll convey my grimacing expression better) by every person who uses it. That's either going to change, or... well, people will keep complaining until it does change. There is no real other outcome; the chorus will just grow louder until patches start flowing, and until one of them goes into the master.
4. The Lines Between DVCS, Database, and Filesystem Will Blur
I think the next interesting DVCS innovation will be storing repository metadata in an abstractable layer - and that the metadata backend that will be particularly interesting will be the database-backed ones. Mercurial is in a good situation here, because Python 2.5 has sqlite3 built-in. Advantage Mercurial.
On the flip side, though, this will require treating repository metadata and file data separately, and that's something that Git already does. Deuce.
This separation will make gitweb-style services very interesting - repositories could simply be database rows, ditto for trees (to stick with Git terminology). The trees would form a graph of objects, either pointing to other rows or to file SHA1s. All those files could objects stored in a shared, either globally or per-repo, content-addressable filesystem, presumably using SHA1 as that address.
Do My Homework (Or Hobby-Work, anyway)
This is actually something I've been meaning to do. It'd be perfect for deploying, say, on Amazon's S3. Hint: Hashes make for perfect bucket keys. Unfortunately, I just don't have the time, at least not right now. But the time to author this was doable, so it's what I did. I hope it helps someone, or at least mirrors what someone else has been thinking as well.
More Wiimote monkeying with Johnny Lee
On Johnny Lee's website, he discusses (and shows video off) his latest computer-human interaction research at Carnegie-Mellon using the Wiimote. In the above video, he gives a presentation on different types of flexible, foldable displays using the motion tracking of the Wiimote and IR LEDs (and projection) to simulate the displays. On his page is also a Cambridge video on how to do 3D motion capture for around US$100 using two Wiimotes and stereo triangulation.
More Wiimote Projects - A Brain Dump
Network
|
|
|
|
|
pam zerbinos (mutual) friend |
|
|
|
|
|
Kumar McMillan (mutual) friend |
|
|
|
|
|
Chris McAvoy (mutual) friend |
|
|
|
|
|
Ian Bicking (mutual) friend |





