ianb

I use this a lot, and it really does work. It renders everything, and renders it well. The one thing that doesn't work is maps – just too many vectors, and Javascript/Canvas/etc just can't keep up. Otherwise I'm very happy and don't feel nearly as much resentment towards PDFs as I used to.

Added to that, DDT was being used in very high amounts as a pesticide, but didn't need to be used in nearly as high levels for suppressing malaria.

Resistance to DDT has formed anyway: http://en.wikipedia.org/wiki/DDT#Mosquito_resistance – though again this is because of agricultural use, not from disease prevention use.

On the other hand, it's not that clear to me that DDT has actually been discarded?

The article on safety this article links to is a year older than the article itself (though same author). It doesn't seem responsible to me to leave out a year of analysis of the effect of Fukushima, and I don't think it's been a particularly positive year. In some ways if Fukushima was a result of human error (as that report indicates), then that's positive: it's resolvable. But if we scaled nuclear power up to 10x what it currently is I would worry about more human error, and introducing nuclear power to places that have even more problems with reliability, or cultural problems with creating reliable systems. A nuclear power plant in Nigeria? I'm sure there are very reliable people who could staff and monitor the plant, and that those people could be attracted to the jobs, but I don't trust the political infrastructure of the nation to ensure that all actually happens. That no one uses shoddy concrete, or pushes problems under the table instead of resolving them and opening oneself up to blame, or manipulates risk assessment to protect their personally acquired power in the working of the plant.

These are disorders that effect a person's personality, which could mean all sorts of new variables to control for. A man who has mild symptoms of autism or schizophrenia may well take longer to establish himself in his life and have children.

Lots of these kinds of push templates have existed, none of them seem to have legs. I think they seem elegant, but mixing logic and HTML is actually just a great way to do things. When you want to change something you see in the HTML – be it dynamic or static – then you always know where to look. And when you come back to some code 6 months later you'll really appreciate the simplicity.

Even in Javascript traditional templates have seen a surge in popularity, even though push-style templates have always been the more natural way to operate (in the case of Javascript, modifying the DOM directly).

Nothing? As far as I can tell they went into a church, a public church (though maybe under false pretenses) and performed while being filmed, against the wishes of the people there, and I'm guessing were asked to leave and did not do so. You could come up with crimes in the U.S. for what they did, but convictions wouldn't happen, and anything more than minor legal harassment is unlikely. And if some zealous prosecutor did put forth some effort the defense could and would be robust, and it would take a long time, and it would be very questionable what the outcome would be, with a wide variety of available defenses. The people who end up in jail over stuff that seems minor usually put forward a terrible defense.

People do stuff like this all the time in the U.S. – this is performance art, and no more intrusive or offensive than typical performance art, and those people don't go to jail. And Alabama churches aren't some otherworldly place.

> His current role is to get beaten occasionally by the police and to remind Western audience that Russian president is evil.

Maybe so. I for one have been reminded that the Russian president is evil.

We've built a little nook for packages on our front porch, I wonder if more people will do that sort of thing as well.

In the marketplace consumer expectations can get higher, a sense of entitlement develops, and that entitlement can be the valid effect of genuine progress. Not because the providers have to satisfy our sense of entitlement, but because they do, because that's what it takes to compete until at some point that's what's expected just to play the game. Food providers at some point stopped competing on food safety because everyone demanded everything be safe. We started expecting cars to be very reliable, and if someone makes an unreliable car then fuck caveat emptor, it's not going to become a matter of whether some consumers are willing to make that compromise and some are not – instead your brand becomes shit and you have to beg people to come back, if you can at all. Right now we don't have that expectation about APIs; but some people want us to, we are moving that direction, and maybe we will get there. Or maybe we'll get somewhere else; progress however ensures that we will get somewhere, that consumers will find something new about which to feel entitled.

And yeah, these companies don't "owe" us anything, but consumers (even the subset of developer-consumers) can still get pissed off at them and say shit and that's the fucking market. And maybe it won't mean anything, maybe it'll all fade away... and maybe it won't. That's the risk those brands are taking. It's our market-based prerogative to bitch about whatever the hell we want to bitch about, using whatever hyperbole we want, with any sense of entitlement that we've acquired.

If someone starts sending mail bombs to these companies because they aren't tending their APIs as we'd like, then that's coercion. But there's no coercion here, this is just people offering their opinions. So quit yer whining about our whining, the internet has entitled us to whine as much as we fucking want to, and has offered market-based ways to lift or bury that whining.

I think you are confusing "missing a requirement" with "not prioritizing a few other people's requirements". That pip is missing this feature has always been documented, I always knew it was a missing requirement, but I did not have any personal motivation to resolve that.

My own opinion, being more knowledgeable about Python's import than I wish I was, I feel like Node.js's require() system is what I wish Python's system was – some of the same simplicity of Python, e.g., with externally-defined names (not a name embedded into the source itself), but with a much more comprehensible and less magical loader.

It gets bad if you use pip and easy_install with namespace packages. If you stick to one or the other you should generally be okay.

But yes, just use socratic_{name} – it makes everything easier, and "." and "_" are just string differences. The only good reason IMHO for using namespace packages is because you are breaking up an existing package into multiple packages and you want to keep the dotted names. And even then I might just prefer a compatibility package that does the mapping and move things to entirely new package names.

I didn't put binary support into pip because (a) it didn't work well on some systems, and (b) I didn't use the other systems. I am not aware of rejected patches to support binary packages on Windows (where it would be nice to include), or even rejected patches on other systems (where I think it would be misguided).

That this functionality still doesn't exist years later I think is due in part to the problem domain – people find it easier to change parts of their workflow than to add this functionality, and the whole problemspace is kind of hairy which makes it hard to advance without causing regressions in somebody else's weird workflow. (And admittedly the code is hairy too – but who wants to fix that? I don't! No one does!)

"It is far easier to take a fundamentally-streaming stack and layer conventional request-response on top as a special case than it is to take a conventional request-response stack and layer a stream on top of that."

This is demonstrably true in that Rack/etc are themselves almost always built on top of conventional socket-based streaming APIs. Streaming APIs have been the norm, and yet people choose to put abstractions on top of them. Why? Mostly because it gives substantial improvements to application code, and turns the system into more of a set of contracts and less of a mushy touch-any-object-you-want system, which I think is fundamental to how streaming works, due to its imperative nature.

Using Rack or any of its equivalents, it would be fairly easy to allow a hole to be punched through the system to give a direct socket streaming API. Just toss the relevant objects into the request. It would violate the abstractions of Rack, any middleware, etc. But you can do it, and it would be easy. It's not unlike using Rack instead of the abstractions Rails puts on top of it – arguably it can be useful shortcut parts of the stack.

Why don't people do this? Mostly because no one cares to. It's not that useful or interesting or testable. It's noticeable enough that people complain about it, but not noticeable enough to be worth it to take the hit and use a more imperative API.

Ugh, the links are a maze of introductions. Here's the real site: https://webmaker.org

"Mature" and "high quality code" are largely unrelated attributes. Given that CloudStack was developed as proprietary code this criticism seems unsurprising.

Thanks for noting this (speaking as the WebOb author). I should say that I don't think WebOb is particularly contrary to the idea being put forward – instead, WebOb was written with this kind of concept in mind.

Requests certainly adds a lot of stuff, some that is below WSGI (e.g., Keep-Alive – WSGI specifically avoids that level of transport), a bunch of stuff that is more stateful (the session stuff), and a bunch of stuff that just felt like it was moving around too much to put in WebOb (e.g., OAuth).

That said, there's nothing keeping a client library from adding that. TransparentProxy for instance could instead be something that handles pipelining and statefulness, and perhaps also acts as a request factory. WSGI is rather helpful here because it does not try to touch those parts – it leaves things open for other tools to take control there. Also to make a better client library you could subclass Request and add functionality that is handy but hasn't been added to WebOb (WebTest does this for functional testing, as an example). Auth probably fits in there. Redirect handling could go in there somewhere too. But if you always redirect transparently then you've made permanent redirects useless.

WebOb itself certainly isn't a client library, its scope is largely limited to representing HTTP requests and responses. But if you are looking for HTTP-related tools, it has a lot of them.

Philip J. Eby was the author of WSGI, not myself. But which mismatches are you referring to? I've frequently heard these complaints, but generally they are fairly obscure things (which are hard to resolve because we can't form a quorum of people who actually care), and a lot of vague FUD.

Mozilla has been hiring quickly, and still puts some money in the bank. Most money is spent on employees.

Ah, but remember this castle? http://3.bp.blogspot.com/_jX9QklC3G4E/TIRfrl9uVRI/AAAAAAAADK...

That was one really great toy.

Since people are throwing out similar kinds of implementations, here's my pattern matching library (which is kind of the same thing as multimethods, but allowing more arbitrary matching than just based on type):

http://svn.colorstudy.com/home/ianb/recipes/patmatch.py

If making a building involved stacking blocks then it would be pretty easy for humans to make buildings too. I don't see how these robots would be capable of installing an electrical socket, or applying caulk, or any number of important tasks. Not to say a robot couldn't accomplish these things, and maybe a quadcopter could deliver supplies in some limited circumstances, though a robotic crane could deliver things as well. One robotic crane could actually assemble the entire described structure, only with concrete blocks instead of polystyrene. It's the eclectic nature of buildings that makes them hard to build, not just piling materials into place.

If you install gnome-shell, everything works quite well.

Mozilla is dropping the idea that some features are point releases and others are major version numbers. As a web browser there's always only been one web, so if a feature is ready then it's ready and it doesn't matter. Internally there's an actual product that other people might interact with -- and Firefox more than other browsers at that, as the traditional way to extend Firefox is to monkeypatch your changes in. But it was never quite so clear what a point release was there either, and it was getting in the way of advancing the core product.

I think simple dated releases would be an improvement (e.g., Firefox 2011.1, 2011.2, etc., or tag them based on month, this one being 2011.10, or 2011v2 or whatever.) But that's basically just a PR move. There's no longer anything really like a point release except in the case of regressions that demand an immediate fix (as happened with Firefox 7).

While Assange has caused problems for WikiLeaks, I think he has accomplished something that is not really talked about in this article, and that is important for any WikiLeaks replacement: he turned those leaks into news. It's all too easy for information to be leaked and no one to care, even if the leaks seem important. Assange helped by being the face of WikiLeaks, and I think he's also done good work working with journalists to get the news out there. Not that journalists and Assange have had a happy relationship, or even a healthy relationship, but he did manage to get real coverage.

I would worry that a committee organization will be too conservative and technocratic. That is not an inevitability, of course; if the committee understands the importance of publicity maybe they can delegate appropriately... but it's not something a group of people can really do well together.

There's some justification in deferring to user interface designers with respect to the vision for the interface. An authoritarian system can work, though you should be sensitive to how you present that authority. "wontfix" is socially dangerous to use.

But authority only works if you use that authority to do the right thing. Unity isn't doing that. I am in part frustrated that Unity got _worse_ with the latest Ubuntu release, and I'm frustrated that it has lots of bugs, and the interface is neither traditional nor discoverable. But even worse than these problems is the problem that Unity isn't pursuing a worthy goal. It's a rethinking of how you manage applications and files on the Linux desktop, but the Linux desktop has never been particularly functional or filled out and it falls behind further with time. The major trends we see is the desktop spiraling in on a single application, the browser, and files and media moving to the cloud. Unity is messing around with something that will never win the hearts and minds of new users, while it alienates what users there already are. I've never met someone who loves Unity! There's a couple people who accept it, and a much larger group that hates it. (Personally once I figured out to install gnome-shell I can like Ubuntu again, but Unity really did almost push me over the edge to get a Mac.)

It's not to say that a rethinking of the Linux UI is an entirely useless endevour, but Ubuntu and Canonical should not be pursuing a fantasy of a rich ecosystem of GUI apps. There are maybe a dozen relevant applications on Linux now, and that number will only get smaller. But the beauty of this is that if you just pursue an experience that encompasses those dozen applications, and you dive deep into those applications (which you can because they are all open source!) then something really neat could come out of that. I think people could get behind an idea like that, even if those same people simultaneously felt annoyed with particular changes that came from that. But it's hard to look past those problems when it feels like present usability is being compromised for a misguided fantasy.

I think there's something very patronizing and morally inconsistent about the kind of argument that is described in that article. Underlying its argument is a belief that the lives of all the people who die aren't important, that these deaths are somehow the proper and natural balance. In some ways it may echo the cultures themselves; when life is precarious and lost for no outward reason (such as by a disease like malaria) then individual life loses some of its meaning, people value not only each other but even themselves less.

Medically there's a tone of what-doesn't-kill-you-makes-you-stronger, which is kind of bullshit. Malaria might not kill native adults very often, but it is not harmless.

And economically, the argument is similarly patronizing. After going on about the native immunity many people have, it then talks about how economic disruption is causing migrations, leading to people (not just whites) who don't have the immunity to be exposed. The response: people should stay in their place. That the prerequisite for solving any problem is to revert to traditional structures and strengthen those structures (the same basic argument is made about poverty and many other African problems). The idea that Africans may in fact wish to have control of their own personal destiny is disregarded -- that if conditions were better, if economic forces were less manipulative, people might still want to migrate, because the drive to better one's life persists even when life is okay.

I feel like it's a form of opportunity cost that creates an imperials debt. Decentralization, and even more so all the motivations that lead developers down the path of decentralization, has nothing to do with making a good social network. It's like all the solar-powered cars... a cute idea, but no one ever (ever) buys a car for fuel efficiency. You buy a car to travel, to carry things. So the solar cars are cute, but they fail at everything a car is supposed to do. You can't possibly improve on something unless you start by implementing the thing.

People will rightly tell you that it does not. But I must admit that this did get me to thinking about a few small changes to WebOb along with the integration of WSGIProxy, at which point there would be some real similarities.

Looking at the states, I think corporate headquarters might be a big part of it. Why else would Arkansas be on the list of net givers? (And Minnesota has a relatively many corporate headquarters.)