Paul Natsuo Kishimoto - 2010

Pork and Beans

2010-10-23T00:00:00+02:00

This is the first entry in what will be a regular feature on life in Boston—including Cambridge & MIT—mainly aimed at family, friends, colleagues, acquaintances, etc. (you know who you are) from Toronto—including Mississauga & UofT. The title comes from the nicknames Hogtown and Beantown. "Pork & Beans" is also a Weezer tune with a meme-packed music video, and the Bosstone musical joke was already taken.

My aims are…

to give you a sense of what it's like to live here,
to make you want to visit me, and
to make sure I don't forget what makes home, home!

I'm also curious if more people will read and comment on these than on previous posts, i.e. if gonzo journalism will prove more engaging than my usual wonkery. At the same time, I'll try to avoid merely touristic content. Expect new entries once a week or so. Whether the two months since my 20 August arrival will ever get backfilled is uncertain.

Why I'm here (in 60 words or less)

I'm studying in the Technology & Policy Program (TPP), a two-year master's program leading to an SM degree. There's both coursework and research involved. It's part of the Engineering Systems Division at MIT, which also has a PhD program that I intend to get into. Why policy? Perhaps read more of this website.

MIT by the numbers

We all like numbers. Consider some data about four entities: the University of Toronto; UofT's Faculty of Applied Science and Engineering; MIT; and MIT's School of Engineering.

	UofT	APSE	MIT	SoE
Undergraduates	33,371	4668	4232	1886
Grad Students	11,638	1476	6152	2794
Total	~45,000	6144	10,384	4680
Faculty	2551	230	1009	370
Campus area	71 ha		68 ha

Curiously, the UofT Engineering annual report (link above) cites a global ranking for the category of public universities, which excludes rich, private schools like MIT and results in a higher placement. But with roughly eight times the endowment (USD 8 billion vs. CAD 1.3 billion) and one fifth as many students as UofT, it's not a fair comparison. We also see that the graduate/undergraduate ratio is much higher here.

In this context you can appreciate UofT's plans to slightly increase the graduate student population at the St. George campus and shift some of the arts & science student body to the satellite campuses.

Other miscellaneous observations

My residence is in a corner of campus, north of a cross-cutting rail corridor, that is populated by big biotech firms, small biotech firms, and biotech firms of middling size. These include Takeda Millenium Oncology, Novartis, Sanofi Aventis.
There's quite a lot of craft beer in Boston, which is a good thing because the lowest common denominator (PBR, Miller High Life, Bud Light) is low indeed. Some good pours I've had are Harpoon IPA, 21st Amendment IPA and Green Flash Double Stout. Unibroue stuff also seems to be popular.
More Mexican food than I've seen in my life, and less variety in everything else (especially Chinese, Japanese, Korean, Indian). I haven't found anything to match Ethiopian House or Mount Everest, and I am overdue to find a place to satisfy a phō craving. It looks like the nearest places are at least 2 km away. Burritos may replace noodle soup as a cheap staple.
That other university has a dragon boat team, but MIT has none. There maybe be four teams in the whole city…if I've missed one. Compare with at least ten teams of varying competitiveness from UofT alone that show up at TIDBRF each June.

This is becoming a bit of a grab bag, and long, so I'll end here. The next post will be more focused on the student body, ESD and "freebies." If there are other things you'd specifically like to hear about please leave a comment!

Fun & games with dbus-python

2010-08-04T00:00:00+02:00

Getting Things GNOME! (well, at least my GSoC branch of it) is on its way to having a feature-complete DBus interface to its data store and the objects (Tasks and Tags) inside of it, as well as a client-side library.

More on that later. This post is a memo of some lessons learned while reading & grokking the entire dbus-python codebase, its still-incomplete tutorial, and trying to make use of it all. Aptdaemon was an invaluable help.

1. Claim your bus…and give it up nicely

This is akin to your mother telling you to, "Clean your room!" Claiming an object path (/org/gnome/GTG/Server) on a bus (org.gnome.GTG) and then silently exiting is a good way to confuse the session bus and any clients who are trying to talk to your object. There's no automatic notification that you're gone; the proxies and interfaces they may be using won't self-destruct. Even the session bus may think you're still there, and tell new clients to look in the wrong place.

This can lead to client code blocking for a long time as it waits in vain for a response—annoying! To avoid this, explicitly claim the bus from the server on startup:

>>> import dbus
>>> dbus.SessionBus().request_name('org.gnome.GTG')

…and on shutdown (even if it's caused by a process signal or exception) be sure to release it:

>>> dbus.SessionBus().release_name('org.gnome.GTG')

You can also do this by creating a dbus.service.BusName instance, but be sure to del it before exiting.

2. Start simply

Like us, you may be able to start the server-side code from the command line (gtg --daemon). Trying to call this directly—for example via an os.popen—is asking for a major headache. There is also no need to muck about with daemonization recipes or ensure the server code runs in the proper environment; the DBus authors and your distro developers have taken care of that.

Instead, make use of service definition files. On Ubuntu, these go in /usr/share/dbus-1/services/ and look like:

[D-BUS Service]
Name=org.gnome.GTG
Exec=/usr/bin/gtg --daemon

From your code, you can invoke this precisely and directly with the single call:

>>> import dbus
>>> dbus.SessionBus().start_service_by_name('org.gnome.GTG')

If the server is already running, the method simply returns a different value.

3. Object paths aren't URLs

In the age of Google, we are accustomed to seeing all kinds of data URL-encoded, resulting in monstrosities like:

http://maps.google.ca/maps?f=d&source=s_d&saddr=Vancouver,+BC&daddr=Winnipeg,+Manitoba+to:Trans-Canada+Hwy%2FON-17+S+to:45.422733,-75.698376+to:Halifax,+Nova+Scotia&hl=en&geocode=FQt57wIdQIKp-CkllQ21IO6FVDEciNbXbMfgpg%3BFYMz-QIdZ5A1-ikRKxr5-3PqUjFkyrnG-hoqKw%3BFTbY6QIdrG7H-g%3B%3BFbFJqQId8Oo1_CnB-tsHFCFaSzHcLYtDpuNrZg&mra=dpe&mrcr=1&mrsp=3&sz=14&via=2,3&sll=45.415865,-75.694084&sspn=0.064467,0.055189&ie=UTF8&t=h&z=14&layer=c&cbll=45.423222,-75.698705&panoid=W0H3GL0BecRylGpWyASQVQ&cbp=12,338.79,,1,-4.03

…and creating a market for URL shorteners. Even file system paths are in Unicode, and the DBus documentation misleadingly suggests:

The object path looks like a filesystem path, for example an object could be named `/org/kde/kspread/sheets/3/cells/4/5`.

Don't get too excited by this. The characters you can use in a DBus object path are: /, a-z, A-Z, 0-9 and _. That's it. In GTG!, we use UUIDs for Task and Tag IDs:

>>> import uuid
>>> str(uuid.uuid())
'9bcb25f3-a630-4030-b82f-cd4cb7b17d65'

So you might guess that a path for this object (a Task, say) could be /org/gnome/GTG/Task/9bcb25f3-a630-4030-b82f-cd4cb7b17d65, right? Wrong. The hyphens aren't allowed, and we have to use:

>>> uuid.uuid4().hex
'4a08654fce994a92b49a8b62ff5a7817'

Similarly, if you want to use human-readable strings (Tag names, for example) in paths, you'll either have to munge them to be acceptable, or deny your users the use of hyphens and spaces. Messy. Much easier just to choose a simple scheme of unique identifiers and pass actual data through actual method calls.

GTG GSoC, week 7 — "Testing, testing, 1, 2, 3…"

2010-07-12T00:00:00+02:00

Recently I have been working on two things related to achieving a client-server separation in Getting Things GNOME!

One is a test suite that will cover all aspects and functionality of the DBus interfaces. The second is low-level code to support the interfaces themselves.

Why not do them in sequence? Well, tinkering with the low level code is helping to outline what will and will not be possible with the "DBus magic" I've blogged about on two previous occasions. Tests don't have to target against code that already exists, but they should at least target code that could exist.

To explain more, the concept is to have more than just a DBus interface on the server. For the client, the dbus-python ProxyObject and Interface classes are a useful starting point, but I want to go further and let GTG! clients behave as if the objects they are handling were local (although, as James pointed out, clients will be faster if they don't naïvely trigger too many calls on the bus). This means providing a client library that clients can optionally import and use, instead of grappling directly with the server's DBus interface.

In coding this client library several interesting winkles have come up. For example, the DBus tutorial discusses the distinction between well-known names ('org.gnome.GTG') and unique names (:34-907)—but these are only for buses. Each object (e.g. a GTG! Tag or Task) available on a bus needs to have an object path ('/org/gnome/GTG/Task/12345' or '/org/gnome/GTG/Task/54321').

Because of the DBus message-passing architecture, there is no way to know if anything exists at a given object path, until you try to access it. By analogy, the Internet's Domain Name System (DNS) can tell you that my website paul.kishimoto.name exists at such-and-such an IP. But to determine if there is anything at a specific URL (http://paul.kishimoto.name/notapage), you need to try to access it and maybe get an HTTP 404 error.

Clients only care about actual Tasks and Tags, and repeatedly checking that its proxies still reference valid targets would be a pain in the neck. The solution is to provide helper code that checks the remote object exists before it hands a proxy to the client.

Another problem that is cropping up is that the client needs to be able to understand and manipulate the tree hierarchy of Tags and Tasks, over the bus. But that will be another post…

Ignorance, or spite

2010-06-27T00:00:00+02:00

Some thoughts on the occasion of the G20 summit in Toronto.

The police presence and violent protest were both of a scale unprecedented for this city. The security cost, at over $1 billion, was also unprecedented in the history of the G-summits and is unlikely to ever be equalled.

Much ink will be shed on the taxonomy of protesters (a term which, apparently, also now includes opportunist vandals with no policy demands), the validity of their various motives and the contemptible nature of their actions. Equally, the actions of individuals among the tens of thousands of police involved will be put under the microscope.

Both those debates will prove fruitless. To me, it is more important to see the three outsized aspects of the event—police presence, violence and cost—as foreseeable consequences of the unnecessary and astoundingly poor choice of a venue for the summit.

I have heard two believable theories about how the choice was made: ignorance and spite.

The 'ignorance' theory was advanced on CBC's The Current by Deborah Cowen of the University of Toronto. She noted that the Conservative government, with almost no seats in Toronto, Montréal or Vancouver, has an essentially rural background on which it draws and little firsthand knowledge about how large cities actually are. The implication is that they might have honestly but falsely believed that the effect of promoting Toronto, Ontario and/or Canada would outweigh any disruption caused by security measures and protests.

The 'spite' theory (of my more cynical friends) holds that the disruption was expected and anticipated by the government. In this view, the decision was to be seen—and appreciated—by the Conservatives' rural base as a giant middle finger raised towards Toronto and its citizens.

The first explanation wins by Ockham's Razor, at least; but whichever is more accurate, it is certain the decision was made for political, not economical (read: cost-saving) reasons.

To explain a bit more why I think the choice was 'astoundingly poor,' and the consequences 'predictable' I will channel Jane Jacobs, late Torontonian, whose The Death and Life of Great American Cities I recently read and enjoyed. Any errors in my paraphrase of her writings are, of course, my own.

One of Jacobs' criteria for distinguishing Great (very big, large scale; important) Cities is diversity of use. On a summer weekend in Toronto, the downtown streets might be used by shoppers, baseball fans, theatregoers, businesspeople, diners, marketers, people-watchers, store clerks, deliverymen, walkers, those passing through to the lake or parts west, east or north, local residents, café patrons, cyclists, taxi drivers, buskers, runners, transit staff, and a whole cast of others my imagination is too weak to summon. The vast majority of these people are strangers to one another, but their mere presence civilizes the streets, so that events like the 2005 Boxing Day shooting of Jane Creba are truly rare, unexpected and shocking.

Jacobs contrasts diverse use with the atmosphere in single-use residential projects, where the same advantages (many eyes at all hours) are not enjoyed and, not coincidentally, comparatively more gang-related violence occurs.

During an event like the current summit, normal usage is suppressed. Within the security perimeter, there is no use at all by locals. Security measures impede normal use in surrounding areas, so that the Blue Jays and theatres take their business elsewhere or cancel whole performances (even at large cost). People who would have attended these larger events have no reason to be in the same areas for meals and other secondary activities. The secondary businesses they would have frequented, always sensitive to demand, run reduced staffs, further depleting the stock of people on the streets. And so on. In the current, extraordinary situation, even residents flee who are able to stay with friends in the suburbs or out of town.

Note that at no point is a collective decision made along the lines of, "Let's turn over the streets to rioters!"; instead, the deadening is an aggregate result of reasonable responses by normal individuals.

The few uses that remain can be numbered on one hand: peaceful protesting, spectating (both amateur and professional), policing and violence. The dead streets are a boon only to those engaged in the latter two activities, who find it easier to identify members of the other groups without actual citizens around.

Without any hysterics about professional anarchists or police agents provocateurs, then, it is easy to see why emptying the city invites situations that would be impossible under everyday circumstances. That this conclusion can be reached on the basis of accessible, popular writing from the 1960s makes me doubt that no one in government raised an objection to the choice of location. Mayor David Miller and other representatives of the city claim openly that they put forward the Exhibition grounds (which, note, are already largely empty) as an alternative.

Those voices were obviously disregarded when the decision was made, and that disregard is the root cause of everything we have witnessed.

GTG GSoc, week 4 — Magic, dates, specs and more shuffling

2010-06-20T00:00:00+02:00

My fourth Getting Things GNOME! Summer of Code week had four work foci (a trend which will hopefully not continue 'til week 10…)

One, I put up some code to the Planet, having been encouraged by good responses to earlier queries. This time I stuck my neck out by proposing something larger, and in short order was told three new things to consider—for example, the mixin concept. With this input, I have improved my FancyInterface, which lets you access DBus properties as Python attributes of ProxyObjects. Check out the code (standalone, for the moment) here.

Many of the the fields in the GTG data model will be exported as DBus properties using the above code. These chunks of XML code give an overall picture of the interfaces that will be used in GTG, in the standard DBus introspection format.

Third, I've proposed a new Date class for GTG. Dates in GTG go beyond what's provided by the datetime module, because we support some 'fuzzy' concepts like now, soon and later. Not only must these be stored and sorted (alongside fixed dates and non-/null dates), but they'll have to go over DBus as strings once my project is complete…hence the new class.

Fourth and last, the divorce proceedings for existing code continue! With OfflineIMAP (highly recommended) as my inspiration, this merge will make the "gtg" executable your one-stop shop for GTK, command-line and other, future UIs. Forcing "gtcli" and "gtg" together helped me see which dependencies were of one UI; which were of all UIs, and which things are needed by both the UIs and core.

Class attributes with dbus-python

2010-06-14T00:00:00+02:00

DBus is great, and so is Python—each for their own reasons. One mismatch is that everything passing over the bus must be a message or signal. You wind up with Python code that looks like

proxyobject.SetThis('foo')
bar = proxyobject.GetThat()
proxyobject.DoSomeOtherStuff()

But then you realize the dbus-python binding is very Pythonic, so you can extend it in a Pythonic way. Here's something I banged together in about half an hour:

 import dbus

 class FancyInterface(dbus.Interface):
     """A fancier DBus Interface.

     Derived classes should define a list of strings __dbus_properties__ and a
     _dbus_interface. For every listed property ('foo') the named interface
     should support two methods:
       * GetFoo() -- accepts nothing, returns a single value.
       * SetFoo(..) -- returns nothing, accepts a single value of the same type
         as GetFoo.

     Then DerivedClass.foo may be accessed as if it were a normal variable.

     """
     def __init__(self, object):
         # next four lines from dbus.Interface.__init__()
         if isinstance(object, dbus.Interface):
             self._obj = object.proxy_object
         else:
             self._obj = object
         # set up properties
         for a in self.__dbus_properties__:
             fget = lambda self: self._obj.get_dbus_method('Get' +
               a.capitalize())()
             fset = lambda self, value: self._obj.get_dbus_method('Set' +
               a.capitalize())(value)
             setattr(self.__class__, a, property(fget, fset))


 class Sample(FancyInterface):
     _dbus_interface = 'com.example.SampleInterface'
     __dbus_properties__ = ('foo', 'bar',)
     def __init__(self, object): FancyInterface.__init__(self, object)
     # this class is 'empty' otherwise…

Using FancyInterface, it becomes even easier to forget you're talking to a proxy of a remote object:

bus = dbus.SessionBus()
o = Sample(bus.get_object('com.example.SampleService',
  '/SomeObject'))
o.foo = 'Hello, '
o.bar = 'world!'
print o.foo, o.bar

Look for this stuff being used in GTG in the near future! (Also, fixes to my blog CSS…)

GTG GSoc, week 3 — Grilled cheese sandwiches!

2010-06-12T00:00:00+02:00

The third week of my Summer of Code project (separating client and server parts of Getting Things GNOME!) was a busy one.

In some long but well-reasoned discussion on the gtg-contributors mailing list, we reached consensus that the GTG data model will add task duration, and drop an older kind of task ID in favour of UUIDs. The duration field will let users estimate how long it will take them to complete a task or set of tasks. As for UUIDs, the benefit ("universally unique") is in the name!

One other proposal—adding a priority field—is still under debate.

Also, the first part of an aforementioned code reorganization went in. (Of about seven bzr branches I've had merged with lp:gtg, the biggest are 1909, 624 and 225 lines, a trend which might continue…but still no match for this!)

This week and next, my biggest task is deciding which DBus interfaces should be exposed by the server part of GTG, and what each one should look like. It turns out that when your application is a delicious grilled cheese sandwich of usefulness, the decision to pull it apart means you need to deal with a glue-like mass of sticky, melted cheese.

…maybe that food-based metaphor will only work for fellow Canadians. What I mean is that a line needs to be drawn across the codebase demarcating what is "server" and what is "client", and in any moderately-complex application that line ends up crossing many, many function calls. The sheer number of these, a non-issue for a monolithic app, becomes problematic because each will need to be spec'd and later maintained to spec.

In this case, the way out was to grep up a list of calls from the GTG UI to GTG core. Examination of this list suggested several ways to streamline the flow of data, which become work items that give me lots of coding to do. Onward!

GTG SoC, week 2 — GNOME's Next Top Model

2010-06-07T00:00:00+02:00

Following on my last week's work mapping the Getting Things GNOME! data model, week 2 of my GSoC experience involved preparing this somewhat-lengthy analysis of how we store tasks in GTG, and how it should change. Of course, it doesn't hold a candle to things like the 168-page iCalendar RFC…of which a good ten percent is devoted to the recurrence specification grammar for VEVENTs and VTODOs.

Needless to say, I recommended we find a more straightforward way of solving this bug. To make you read the actual analysis, I won't give away my other conclusions here!

I have also started a page for user stories to guide future development, and begun moving around large blocks of code to start to tease apart the user-facing and core portions of GTG.

Some questions for the Planet hive mind:

Which is preferred idiom — import sys; sys.exit(1) or raise SystemExit(1)? The latter avoids an import…
Likewise, most modern PyGTK applications include a pygtk.require('2.0') wrapped in a try/except clause. Is this suggested/required in every file that imports gtk, only the lowest level, or only once per application (presumably in the root or top-level UI module)?

Getting Things GNOME!

2010-05-29T00:00:00+02:00

Hello, Planet GNOME! I'm Paul Kishimoto, working this summer on Getting Things GNOME! as part of Google's Summer of Code. You've already heard from Luca and Karlo, my partners in ~~crime~~ coding.

To complement both Karlo's web-based interface to GTG (which will let you access your tasks from anywhere) and Luca's multi-backend overhaul (which will let you store them anywhere), I will be working on a client-server separation in GTG. If you are interested, you can read details in my work plan.

The possibility of client-server separation in GTG will be largely enabled by the wonderful DBus. Accordingly, I have spent a good amount of time vacuuming down the excellent DBus documentation in an effort to get beyond being a mere hacker and to the point where I can exploit its features fully.

Once you board the bus, there are many people already on it to talk to. It also turns out that some of those people care about tasks, in similar ways to GTG!, and furthermore there are other task enthusiasts who don't yet ride the bus. So, my second work item for this week was to map out exactly what GTG thinks a task is, and then go about comparing it to other tools, including (in no particular order) Tracker, Hamster, Zeitgeist, Planner, and more.

Understanding these relationships is key to making GTG! work together closely and intelligently with whatever set of other applications each user prefers, ultimately giving them the freedom to work in the way they want.

A very simple creature

2010-04-05T00:00:00+02:00

Recently several people have expressed frustration, within hearing range, over infuriating actions of large companies. For example, Apple's practice of generating excessive hype for unremarkable hardware by applying a spot of polish and a kiloton of marketing. Aggressive lawsuits and patent trolling are another instance. Attacks on the reputability of excellent sources of journalism are a third.

The corporation is a paradox. Unlike the human beings that own and work for it, the corporate entity can be physically massive and far-reaching, to the point of incomprehensibility. We are hard-pressed to even picture Toyota's 300,000 employees, or the 9 million cars it sells annually. Conversely, while the behaviour of their employees and investors as individuals is complex, corporate 'behaviour' is very simply-motivated.

In fact, it is not reductio ad absurdum to say that nearly all business ventures have a single purpose: to generate a return on investment. This is an ineluctable truth, their raison d'être.

With this in mind, we see that it is unreasonable to treat corporate behaviour as if it were human behaviour. "Singly-motivated" humans are frequently described as insane. Likewise, it is unreasonable to describe corporate behaviour using the human qualities of hypocrisy, audacity, justice, honesty, fairness, consistency, etc.

On the other hand, lower life forms, which respond predictably to changes in their environment, are a good model. If I say that ivy will put roots in weak mortar, unable to know that such action will cause the wall on which it lives to collapse, you can begin to see my meaning.

Bacterial colonies can be made to commit suicide by consuming all the food in a closed container. Similarly, when the return on investment is demanded quickly, the corporation can be expected shoot itself in the foot by generating short-term profit and ignoring (or actively denying) the possibility of long-term repercussions.

There are, of course, attempts to quantify the human impact of corporate activities. In such discussions you hear the terms goodwill, corporate social responsibility, ethical consumerism, and so on. But at root these are ways of assigning monetary value to efforts to limit profit-reducing public backlash against corporate actions which are seen as 'evil'. In nature, small creatures will avoid the unwanted attention of predators and competitors.

Applying this sort of analysis doesn't reduce the human damage often caused by corporate actors, but it certainly renders most instances unsurprising. The comparison works best for larger companies, in which the actions of the whole are most divorced from any good intent of the many individual employees. It also explains why we tend to see fewer 'inhumane' behaviours from non-profit organizations and charities. Freed of the overriding imperative to generate returns, these entities can adopt decision-making structures that tend to increase other outcomes.

Finally, to my mind, the analogy clarifies the issue of public versus private provision of government services. To shoehorn the positive societal impacts we expect from certain government programs into the measure of profit or return on investment is often inappropriate. Even where it is, private service providers can only be expected to yield the desired outcome if the direction of increased return is carefully aligned with more positive societal impact. On the other hand, as outlined above, the same providers can be expected to find all new ways of generating returns which do not necessarily correspond to any societal improvement—bursting like so many blades of grass through cracks in the figurative pavement.

Obesity

2010-02-16T00:00:00+01:00

I have almost finished reading the brilliant book Beyond Growth by the economist Herman Daly. It is worth quoting at length:

We have three economic problems to consider: allocation, distribution and scale.

Allocation refers to the apportioning of resources among alternative product uses—food, bicycles, cars, medical care. An allocation is efficient if it corresponds to effective demand, that is, the relative preferences of the citizens as weighted by their relative incomes, both taken as given. An inefficient allocation will use resources to produce a number of things that people will not buy, and will fail to produce other things that people would buy if only they could find them. It would be characterized by shortages of the latter and surpluses of the former.

Distribution refers to the apportioning of goods produced (and the resources they embody) among different people (as opposed to different commodities). Distributions are just or unjust; allocations are efficient or inefficient. There is an efficient allocation for each distribution of income.

Scale refers to the physical size of the economy relative to the ecosystem. The economy is viewed, in its physical dimensions, as a subsystem of the larger ecosystem. Scale is measured as population times per capita resource use—in other words total resource use—the volume of the matter/energy throughput (metabolic flow) by which the ecosystem sustains the economic subsystem. Scale may be sustainable or unsustainable. An efficient allocation does not imply a just distribution. Neither an efficient allocation or a just distribution, nor both, implies a sustainable scale.

The three concepts are quite distinct, although relations among them exist, as noted above.

(I had planned to write on this topic, but instead put a gift card towards this purchase—a lucky choice, in hindsight. Usually I am happier to read on new topics than to share my clumsy initial thoughts. Experience is starting to show this is a good habit.)

Daly points out that economics and the problem of scale cannot escape elementary thermodynamics. Human economic activity takes low-entropy matter & energy as input and produces high-entropy wastes. The ecosystem has a limited ability to convert the latter to the former. He also hints that the scale of the economy is unsustainable, or will soon be at current rates of growth. There are also a number of elegantly simple diagrams I will surely reproduce and reuse.

The very clear explanations lend weight to a number of incubating personal beliefs:

"Ethical-" or "green consumerism" cannot solve problems of _scale_. The much-touted power of individuals making smart product choices is limited to adjusting effective demand, and in turn _allocation_. Really the only choice which can help us (well-off North Americans) solve the scale problem is to _not consume_.
Posturing about "equal treatment" of rich and poor nations in (for example) carbon-limiting agreements is misguided. If there is an optimal scale for the global economy, the corresponding per capita resource use is certainly lower than the current level in the richest nations, or higher than that in the poorest. The necessary adjustments differ greatly depending on which is the case.
As a corollary to the above, poor nations (Daly says bluntly "the South") cannot follow the same historical trajectory of development as the North. China and India, for example, err badly in aiming for the North American level of consumption. North America, unconscious of the image it presents, errs badly in encouraging such aims. We cannot all live this way; the only "fair" thing is that no one try either to achieve _or maintain_ it.
Population control is an inescapable necessity. Either our current 6.8-billion must live in general poverty, or some lower number may live comfortably. It is better to accomplish this peacefully than violently.
In order to muster the political courage to control population, we must first prove to ourselves that we can solve other problems associated with reaching optimal scale.

These considerations motivate major changes, but of course they don't mean that we must choose to be unhealthy, uncomfortable, hungry or unhappy.

More (hopefully) soon.