I wuv you.
You are currently browsing the monthly archive for April 2009.
Sarah and Francesca rock pretty hard. Update: Now available on the Mozilla Community Store!
Paul and Joe also had their bliz-shirts. Because they are awesome. Everyone else wanted to know where you can buy the t-shirt. You can get them on Monty’s t-shirt shop.
I have mentioned this t-shirt before. And because you’ve gotten this far:
It’s earth day so I thought today might be a good day to post this. I’ve been sitting on a set of tabs in my browser for a long time now – months I think – and I think that it’s enough to be able to share with people.
Over the last few months I’ve been working hard to wrap my head around the issues of climate change and what it might take to be able to deal with it. As of late I’ve become a pretty data-driven person. That is, I want to have a decent amount of information about how to measure a problem, but also what it’s going to take to solve it. I thought that I might share what I’ve seen out there that’s really put things into perspective for me.
The Size of the Problem
I’m going to share three links here that I think underscore the scope and scale of the problem. The first two are from Stewart Brand, the last is quoted by Michael Parekh but is from another article. The assumptions that underlie this set are that:
So that being said, here are some links that I’ve used to understand the problem.
Quoting Stewart Brand:
The world currently runs on about 16 terawatts (trillion watts) of energy, most of it burning fossil fuels. To level off at 450 ppm of carbon dioxide, we will have to reduce the fossil fuel burning to 3 terawatts and produce all the rest with renewable energy, and we have to do it in 25 years or it’s too late. Currently about half a terrawatt comes from clean hydropower and one terrawatt from clean nuclear. That leaves 11.5 terawatts to generate from new clean sources.
…
“Two terawatts of photovoltaic would require installing 100 square meters of 15-percent-efficient solar cells every second, second after second, for the next 25 years. (That’s about 1,200 square miles of solar cells a year, times 25 equals 30,000 square miles of photovoltaic cells.) Two terawatts of solar thermal? If it’s 30 percent efficient all told, we’ll need 50 square meters of highly reflective mirrors every second. (Some 600 square miles a year, times 25.) Half a terawatt of biofuels? Something like one Olympic swimming pools of genetically engineered algae, installed every second. (About 15,250 square miles a year, times 25.) Two terawatts of wind? That’s a 300-foot-diameter wind turbine every 5 minutes. (Install 105,000 turbines a year in good wind locations, times 25.) Two terawatts of geothermal? Build 3 100-megawatt steam turbines every day-1,095 a year, times 25. Three terawatts of new nuclear? That’s a 3-reactor, 3-gigawatt plant every week-52 a year, times 25.”
In other words, the land area dedicated to renewable energy (“Renewistan”) would occupy a space about the size of Australia to keep the carbon dioxide level at 450 ppm. To get to Hanson’s goal of 350 ppm of carbon dioxide, fossil fuel burning would have to be cut to ZERO, which means another 3 terawatts would have to come from renewables, expanding the size of Renewistan further by 26 percent.
Reading the whole mail is important and eye-opening. You should do it. I think that this message alone puts into perspective the sheer mind-numbing amount of work that has to happen to be able to effectively protect our planet from ourselves. When I hear about eight or even fifty billion dollars aside to help with these problems I chuckle. Because it’s only a small portion of the amount of our own efforts that’s required to be able to make steady progress against this growing problem. More on that in the “Making it Personal” section below.
2. Climate Change, Recalculated
This is a pretty long presentation, but thumbing through it is worth your time. He goes into talking about the basics of energy, what a “watt” is, etc. It’s a pretty important concept for everyone to understand – not just because they need to be able to measure their own energy footprint, but also how various technologies offset that footprint.
He also takes the time to talk about the scale required to solve the problem. Talking about the US industrial output, what it was during WWII and how that might relate to us starting down the path to fix it. You should take the time to thumb through this – slowly. It will really alter your perspective.
3. Michael Parekh on “The Hummer of Food”
The livestock sector is estimated to account for 18 percent of global greenhouse gas emissions and beef is the biggest culprit.
Even though beef only accounts for 30 percent of meat consumption in the developed world it’s responsible for 78 percent of the emissions, Pelletier said Sunday at a meeting of the American Association for the Advancement of Science.
That’s because a single kilogram of beef produces 16 kilograms carbon dioxide equivalent emissions: four times higher than pork and more than ten times as much as a kilogram of poultry, Pelletier said.
So yeah, I guess the lesson here is eat less beef. It’s a pretty simple idea, too. I just thought that pointing out that even small changes in lifestyle can still have a pretty big impact on the world – if we all do it.
Making it Personal
So by now you’ve spent the time to read through this and you have a better sense of both what it’s going to take to fix the problem but you don’t have a sense of what it takes to start making a difference in your daily life. My suggestion? Wander over to WattzOn and start building your own energy profile.
They have compiled a huge database of products, services and personal action and how those things translate into your energy footprint. For example, building a car requires a huge amount of energy so if you own one that should be counted in your energy footprint. If you replace your car every 6 years instead of every 3, that saves energy. Where you live and how you get to work affects it. And of course, the stuff that’s pretty easy to measure – home heating and electricity. All of that is collected together and you can create a profile. I did this and it was pretty eye-opening.
Here’s my profile as an example:
As you can see it turns out that since I work at home I have almost no commuting cost but it turns out that my flying around the world lifestyle accounts for nearly half of my wattage. Also it turns out that heat and electricity only make up a small amount of my footprint. I was not expecting this when I started the process, which is why I encourage everyone to do it themselves. It also means that I understand how much turning off a lightbulb means in the grant scheme of things and what an incandescent (100W) vs. an energy-saving bulb (20W) really means – not much, but enough to encourage me to do it anyway.
So how much would it cost to offset that footprint with clean energy?
So let’s talk about that roughly 10,000 watt lifestyle – what does it mean? What would it take for me to offset it? I sat down and figured out that I would have to purchase a whopping $275,000 in solar panels (installation not included!) to offset 10,000 watts. Not a small amount of money.
Yes, it’s a strange way to measure it and it doesn’t map to things like air travel but it puts a dollar value on clean generation to drive my daily life. But it takes my personal footprint and makes me understand the amount that I would have to invest to offset it. And it lets me put a dollar value in my head on the value of saving energy through lifestyle changes.
So it’s earth day. Why not sit down and figure out what it’s going to take for you to make the earth a better place?
Google has announced the availability of a plugin that implements 3D technology and makes it available over the web. You can read about the announcement in in the Google Code Blog and in an excellent article by Ryan Paul in Ars Technica.
Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.
Google’s 3D work is a plugin. So much like how Flash or Silverlight works you get a rectangle in the browser to draw into. They provide a high level scene graph API which uses the COLLADA format for loading objects underneath. It’s a very large chunk of code. If you take a look at the API and click around at the packages and classes you can see that there’s a lot there. Their use case is games and game-like things – virtual worlds. So it’s a great piece of work, but it’s also at a very high level.
Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0. It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5. The proposal is very focused on 3D. For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec. We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context. Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it. (Later in this post you’ll understand why this is important.) But the important thing is that it’s something that you can easily mix with the rest of the open web. Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc – you should be able to mix them all together and that’s our goal.
So these two 3D things from Mozilla and Google are pretty different. Not really competitive, either, because they have such different goals. The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.
Given the title of the google blog post (“Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be. We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard. Here’s a quick iteration on those principals in my mind:
1. It’s important to keep the scope as small as possible.
The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation. It’s also the easiest thing you can do to remain as future-proof as possible. It’s easier to add new APIs later if your scope is very very small.
2. Clear rules for interaction with the rest of content.
How does it work with the rest of the HTML spec? CSS? Video? Images? How can you copy content in and out? Can you use them as textures? These are just some of the questions that you have to raise as a way to describe how something like this might work with content. Once again, this is gated on #1 above – if the functionality is simple then the interactions can generally be pretty simple as well.
3. Allow the scope to change slowly over time.
Understanding that technology – especially on the web – does not exist in a vacuum outside of time. Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve. Understanding that standards are an iterative process is important. Note that in #1 above – controlling scope – I mention that it’s important to keep things future-proofed via small and simple APIs. This is why – because you know that you will need to improve that API once you understand how people are using it in the field.
4. Allow most of the innovation to happen next to and on top of your API.
Last point – your standard should allow as much iteration and work to happen on top of your API as possible. This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration. If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster – as long as they are simple APIs. We saw this in the real world with the JS libraries (dojo, jQuery) – we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits. But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.
OK, so those are the things that we think make for a successful standards process. I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.
Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.
Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.
So I’ve spent some time talking about the context for standardization and what makes standards successful. How does this related to our stuff or Google’s stuff? Well, quite a bit actually. If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize. Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin. Their API is a good example of what a scenegraph API would look like on top of Canvas 3D. JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them. Hence a low-level API that we can build on.
There’s a lot of great stuff going on with 3D on the web. We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support. It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.
I’ll be speaking at the O’Reilly Velocity Conference on June 23rd in San Jose, CA. There’s a presentation/panel on What Makes Browsers Performant that I’ll be part of. We’ll have reps from both Google and Microsoft there as well. Should be fun!
If you want to attend, use this code: “vel09cmb” – it will get you an extra 15% off the price.
interesting stuff
