Bug Blogger

Teen Security: S.H.A.R.K.

When I was an early teen, the issue of security was of paramount concern to me.  Not computer, social, national, or even homeland security.  No, it was Room Security.  My room.  The one in the basement.  The mostly unfinished basement that smelled like concrete and pine 2x4's.  I wanted to build an early detection system for parents.  I called it S.H.A.R.K..  It began simply enough with some parts from Radio Shack:  Some infrared diodes, a relay or two, and a piezo electric speaker.  I had a lot of time for this project, and naturally the system requirements exploded.  I didn't really see it that way at the time (thankfully), but I ended up drawing master plans for a general purpose computer.  While not yet introduced to Alan's machines, I knew S.H.A.R.K. needed memory and some sort of execution system.  I envisioned a tape with rows, each where a hole could be cut.  Through a hole light would cause a relay to trip, closing some circuit that was paramount to Room Security and the prevention of unannounced parental intrusion (UPI).  See the tape allowed me to have a modular, dynamic approach to security.  Swap in a fresh roll and have a brand new security strategy.  Brilliant.  Kind of like programming, or modular hardware, or..well BUG.  Sadly my imaginations never actually worked in practice, but I had a bunch of wires in a shoebox and it did something.

This week I have the honor of speaking on Bug's behalf at Maker Faire.  I'm a huge fan of the publication and when reading it get the same stimulating, awesome feeling of creating that I did when S.H.A.R.K. was fresh in my mind.  I'm really looking forward to seeing all the freaky cool things people are doing, and hope BUG makes a few people smile.

One hundred thousand new operating systems.

I have been a huge fan of Gentoo Linux for several years. Why? Is it the elitist appeal of compiling your operating system from scratch? Could it be performance gains achieved by compiler and package optimizations for a particular piece of hardware? The excellent forums? Nope, none of the above. The Gentoo community instills a culture of looking under the hood, of customizing and tweaking, of not being afraid of greasy hands. I get laughed at in the office sometimes because of this and I have to spend more time installing, but I think it's worth it. Deep customization seems to be the wave of the future, and here is why I think so.

Enterprise Application Servers: great idea! Provide a uniform platform optimized for a specific type of application. Abstract the hardware layer with some operating system and a JVM. Serve up Ebay! But why stop there? Why can't the app server run on bare metal? What is the use of all that OS overhead/complexity/variance underneath? In software design, we constantly make compromises between optimization and generality. What if we didn't have to? What if we could develop and deploy an entire operating system for a specific application or job position or organization? Well of course you could but it would be incredibly expensive and take forever. And who's gonna write all those device drivers?

At SCALE in LA a few months back I had the opportunity to see a presentation by and briefly talk with Bruno Gonçalves de Albuquerque of the Haiku project. The concepts behind the operating system are fantastic. The level of optimization at the user experience level when you control the entire OS (read: filesystem) is really amazing, and clearly blows the doors off any desktop OS I've ever used. Why am I not using Haiku right now? Well apart from it not being quite done yet, hardware support. Developing device drivers is a constant and thankless battle, typically undertaken by Microsofts and OEMs. Where is the incentive for a Taiwanese OEM to provide a device driver for Haiku? While listening to Bruno Gonçalves de Albuquerque it occurred to me that this problem may just go away if Haiku had binary compatibility with the Linux driver model. All of a sudden my graphics card works, and my wifi (gasp) too! Linux, besides being an operating system, provides support for a very large number of devices and systems. Fresh off the presss, 2.6.25 supports a new hardware platform. The fact that all of this work is open source presents an opportunity for other OS producers to leverage this work. It lowers the cost and increases the potential user base by supporting a greater variety of hardware. But who cares? We have OS X and Ubuntu and XP. Do we really need another operating system?

On the hardware front things are changing radically. Eight cores today, 64 tomorrow. Specialized (audio, physics, credit card validators) cores on the same chip. There is talk of doing away with the graphics card altogether and putting that in the CPU too. The list goes on... But where is the software? Where are the operating systems and languages and runtime environments to fully take advantage of this latest round of hardware innovation? And who decides where virtualization occurs? Is it KVM...or perhaps some JVMs? Do I have to run one master OS that virtualizes all the others? Can I partition, version, and manage OSs per core? Dynamically? Can I have a custom OS for Crysis III that gives me a few more frames per second because my machine isn't looking for security patches? Do I really have one machine or many?

There is a shift happening in software caused by new hardware platforms. Component based design, concurrency, functional programming, and virtualization are all, in part, results of trying to utilize new hardware designs. This change is similar, but hopefully more fundamental to the shift from single-task operating systems to multitasking ones. From TSRs to Windows. It took so much time for that earlier change to manifest*. What's the difference between then and now? How long do we have to wait for MS Windows 95 part II?

Well I think the difference is Linux and open source. The difference is an open driver model that allows OS developers to focus on new ideas rather than supporting 3000 network cards. The ability to see solutions in the open, and the ability to collaborate. No more silos, no more ivory towers. The demand for radical OS customization will increase as divergence grows between hardware potential and what our existing operating systems, languages, and runtimes are capable of. And as this demand increases I hope to see new, radical, highly-custom new operating systems and runtimes emerge. Exciting times!

* And yes, I had an Amiga too back in 1989. And yes, it was sweet.

Alberto and Bobby need BUGs!

I'm currently reading William Gibson's latest release, Spook Country. I've been a fan of him since first stumbling through Neuromancer as an early teen. It was a very important book for me at the time because of the concepts that technology is not just in the domain of math nerds, NOCs, and ROI, but interacts with almost every aspect of the human universe. Gibson's stories usually involve some kind of hacker immersed in a crime or scandal and, for me, the biggest thrill is in how Gibson's characters modify and subvert top-down megacorp driven consumer products into things of real human interest. How the world, as designed by focus groups and industrial designers, is never really how it turns out in the end. The essence of this of course is Gibson's statement: "the street finds its own uses for things" ("Burning Chrome", 1981).

Back to Spook Country. There are a couple of characters that are involved in an emergent underground art-scene known as "locative art". A viewer goes to a specific physical location and visual art accessed through some network-enabled hardware. Typically pieces have some direct connection to the physical space and there is a direct connection between the digital art and the physical world. One problem Gibson's characters have though, in this near-future tale, is the hardware. There is some vague reference to a cell phone ducted taped to a GPS receiver. More specifically, the problem is that Gibson essentially sees technology as always being generated by massive, top-down systems, and hackers, artists, and criminals subvert these systems for their own needs, but only in highly localized ways.

Is Gibson right? Are we forever doomed to Maas-Neotek decks, Sense/net media, and Sony camcorders? Or will bottom-up, user-directed technologies become popular and skew us all from Gibson's near-term future worlds?

Oh Hai from EclipseCON

What do I love more than lolcats?

Why, EclipseCON of course.

I've noticed a great deal of interest lately among Eclipse bloggers about Bug Labs and BUG, particularly given our involvement with the Eclipse and OSGi communities. So with the buzz about BUG growing, especially as we begin shipping soon, I'm pleased to announce that we'll be showing off the BUG and the Dragonfly SDK all throughout next week's event.

Angel, Alex, and myself will be at EclipseCon 2008 between Monday and Thursday, and attending as many of activities as possible. In addition to our BUG+SV next Tuesday and speaking at the show next Wednesday, we'll also be hosting a BUG+Hack event at EclipseCon on Tuesday and Wednesday. Bug Labs will be camping with Cloudsmith in their CloudLounge, located in the lobby of the mezzanine level of the Santa Clara Convention Center. Stop by, load up Eclipse and your OSGi bundles, and have some fun. There will be some great prizes in store (hint hint: a BUGbundle or two) for whoever makes the best BUG apps by the end of Wednesday.

On the OSGi front, there has been some interesting discussion on OSGI consoles. Looks like there should be a standard at some point soon. Have a wish-list or gripes? Might be a good time to check out the mailing list or come to a BoF (Birds of a Feather) session at the show, as I'm sure the topic will come up.

Lastly, I've been working on a personal project in PHP and gave the PDT project a try. Wow! The PDT team did a fantastic job. It's simple, elegant, and "just works". Reminds me of the profiler we had back in Eclipse 2.11. If you do any PHP development I highly recommend it.

Looking forward to seeing everyone at EclipseCON!

Who cares if the future of mobile Java is open or closed?

Well, I do. :) There is a whole lot of activity these days in the mobile Java/open source world. Harmony, Android, PhoneME, OSGi, and MIDP 3.0 are all causing waves, in one form or another. The latest MIDP JCP, initialized about 3 years ago, has been rumbling towards an initial release as of late. Back then open source mobile Java did not exist in any meaningful way. Well, things have changed. I think the PhoneME MIDP implementation needs to be opened up. If you agree you may want to let the PhoneME engineers know. I'm sure they would appreciate the feedback.

SCaLE: Thanks for the Recharge!

We gave a talk on BUG and some things we've learned about embedded Linux at SCaLE 2008 last weekend in LA. The session went pretty well, and the turnout was great. The audience had some great questions and was, in general, very enthusiastic about BUG. I was surprised by the variance in topics and skill sets present, and at how friendly and inclusive everyone was. Some technical conferences I end up going to seem to have an exclusionary, elitist feel to them, whereas SCaLE participants seemed to be quite at home with each other.

One session in particular was really exciting for me: Bruno Gonçalves de Albuquerque's talk on Haiku. Haiku hasn't much to do with BUG really, but Bruno's excitement and enthusiasm made me remember why I'm typing away at present: the sheer joy of making things...the pleasure in solving problems and the satisfaction that comes from taking something and making it better. At times in the thick of things it can be easy to lose track of that. So, thank you Bruno and to everyone at SCaLE for giving me that much-needed recharge!

GPL + Sun + Java = Try Before You Buy?

From early on (pre-GPL Java) in the development of the BUG we realized that Java-like language features would be a great help to us in providing a consumer electronics platform that is easy to use and modify. In general, we wish to openly enable more people with different skill-sets the ability to create custom consumer electronics devices and applications. Here are some reasons why Java makes sense:

1. There exists a large base of people that can write Java programs.
2. The "Write Once, Run Anywhere" design of Java side-steps many of the pitfalls of traditional embedded development. By simplifying how applications are written, built, and deployed to BUGs, a larger group of of people can participate.
3. A large pool of existing applications and libraries are available, both open source and commercial, that could possibly be combined with BUG to provide rich functionality.
4. Java has a wide variety of rich tools to develop and debug applications, making the process of building software easier.
5. Sun and other companies and institutions have spent a great deal of time and effort on making Java run well in small systems.
6. Unlike many older languages, rich networking support was built in from the beginning.

We experimented with various other languages that had some of these features, but in the end nothing else really stacked up. So we created some early proof of concept systems involving JamVM and GNU Classpath and were pleased to see that open source Java worked and looked to be stable enough for production use. And then, of course, came the Sun announcement that Java ME was to be released under the GPL. We watched with great interest as the phoneME project emerged as open source Java for small machines. We began working with it and found it to be extremely mature and well documented. The development team at Sun have been extremely helpful and diligent in supporting FOSS folks.

So we plowed ahead, building our application layer on top of phoneME. A little JNI here, a little OSGi over there. Everything was coming together and the product matured to the point that we were ready to begin the process of validating our system via TCKs. TCKs are test suites used by Sun and other companies to pass or fail a given implementation of a specification. The are necessary to ensure that different products have consistent behavior. In essence they enforce the "write once run anywhere" design goal. We had a conversation with Sun that went something like this:

Bug: "We use your open source Java product and want to validate it. We want to be able to say it's Java. What are time and cost constraints?"
Sun: "Great! We love the open source community. Please step into our commercial license so we can proceed."
Bug: "Umm...we can't have a commercial license. Our product is completely open source."
Sun: "We're working on our open source validation process. Let us get back to you when we have something in place. Are you sure you don't want a commercial license?"
Bug: "Well, can we pay you for the validation and stick with GPL PhoneME?"
Sun: "Nope, TCKs are only available with a commercial license."

So here we are, a pure open source software stack using GPL'ed Java from Sun without the ability to validate it or even call it Java. What are our options? The same options we've always had with other OSS Java implementations: don't call it Java. We could also utilize another implementation such as JamVM with GNU Classpath, Harmony, or one of several others. As it stands the quality of the Sun implementation and the engineers behind it make it a very good choice, but once you remove the feature of "Java from Sun", other implementations begin to look more attractive. Given the simplest solution, don't call it Java, it seems that Sun is almost ensuring that fragmentation will occur. We have to call it something..perhaps "anything but Java" (abJ)? And without tests how can we ensure compatibility? Of course we can't. Without validation from Sun, we'll need some kind of validation from someone like Apache Harmony or GNU Classpath. Validation is important because it gives us the ability to isolate our bugs from class library and JVM bugs. Sun of course is the gold standard but both GNU and Harmony have validation strategies that look to be effective.

In open sourcing Java, Sun wishes to increase it's usage and popularity, get help from the FOSS community in expanding and enhancing it, and be a successful commercial company by doing so. As it stands now there is a road block in that no community-driven phoneME implementation can be called Java, nor can it be validated against Sun TCKs. Is GPL short for "Try before you buy" at Sun? If Sun truly maintains the Java trademark to ensure that the product does not become fragmented it MUST provide TCK and branding options for GPL PhoneME, otherwise further fragmentation is inevitable.

When do you stop teaching that old lolcat new tricks?

Here is a scenario that may be familiar to some Eclipse developers:

1. Write lolcats manager plugin using Eclipse x.y.
1.2 Build scripts for lolcats is written.  Takes 2x time of writing lolcats.
2. Release lolcats for Ecilpse x.y.
3. Eclipse releases x.z to general public.
4. Lolcats is tested on x.z and it is compatible. (yay!)
4.2 Lolcats build scripts are modified to build against x.z. 
5. You are now supporting Lolcats on x.y.* -> x.z.*
6. Users start sweating for bug fixes and new features only in x.z.
7. Brain starts hurting.

When do you stop supporting older Eclipse releases?  There are some great things in 3.3 that simply are not available in 3.2, and the overhead in forking product that goes through building, testing, and documentation can be very expensive.  Any advice on when to say when?

Context and Software

While proofreading and adding to a technical paper earlier today, I was struck by a general difference between human language and computer language: works based on human languages are much easier to critique and modify than machine languages.  In software, writing something from scratch is usually easier and more effective than modifying some other software written by someone else for your purpose.  (An exception would be frameworks, which exist only to be extended and modified.  Also Vista.)  Why is this the case?  What makes human languages so much easier to modify than machine languages?  Part of the answer I think lies in Context.  (I love context.  I often find myself stumbling around in the context of Context.)  In human language, it's simple and often pleasurable to let someone else wrap you in context, and once there, modification and extension of that work can be natural and straightforward.  In machine language, just getting to that state of contextualization is at best painful and usually impossible.  Machine languages do not lend themselves to climbing from the page or screen into your head like a good book does.  And without being immersed in the context of a system, the work required to modify and extend becomes haphazard and risky.  You start wanting things like contracts, components, and test suites. Can I please just have a skulljack instead?  These JUnits are getting tedious.  It seems that latter day computer languages assume that this greater contextualization of a digital system is impossible, and gains are made by reducing the risks to minimal or partial contextualization.  In fact, some technologies even classify this minimizing of contextualization as a feature. Where would we be in software today if we'd taken the path of focusing on tools and techniques to let the human contextualize more or all of a program, rather than assuming they can't and hope for the best?   blonde, brunette, red-head...

Navigating the Waters of Commercial Open Source

  Just like it's a baby's job to cry, it's a company's job to make money.  There is no need to rehash old cliche question "how can you make money if you give away the product for free."  I think the software world, as it exists in 2007, is proof that we've evolved beyond this initial fundamental question, even if others are having a harder time.  Yet the story has become more complex, more subtle.  One question that I deal with every day is, how do commercial open source companies work together to produce a product?

  In the old days, building a product with technologies provided by other companies meant buying licenses typically, or maybe support contracts.  A financial transaction insures that the companies you depend on will help you make sure their aspect of your product works as it should.  In the real world it's never true that this always works, but it provides a basis for the relationship.  What then becomes the basis when there is no explicit transaction between companies?  Or even when when one company knows absolutely nothing about the other.  In working for a commercial open source company, I've had some interesting experiences finding out.

  First let me say that I'm an engineer and I solve technical problems.  In the old days, after securing a license from a vendor, you get a support contact, and then you're off building your product.  In dealing with open source, after first doing your license compatibility checks, community "vibrancy" checks, you just dig into making your product with various open source bits.  If you're lucky, things work as they should.   Again, the real world is  a little different.  Here's where the interesting stuff starts.  When something doesn't work as expected, I post to forums, send emails to developers, and do a lot of googling.  Openly, brazenly, technical details about my project leak out into public forums.  I ask questions to Sun, to Freescale, and surprisingly they respond.  Solutions that are found to problems are also public.  My competitors could have a head start simply by reading forum posts.  There is no commercial relationship between me and any of these open source software providers.  Should there be?  They have no idea what my product is, who the customer is intended to be (a potential competitor?), or when I intent (if ever) to release my product.  Yet they respond, and they put a lot of effort into their responses.  These are very smart people being payed well (I hope!) to help me fix problems.  Why are they doing this?

  Some companies present the lure of open source, and then attempt to reel you in with a commercial license after the complexities of integration become apparent.  I don't really think this strategy works, because the true values of open source products outweigh any short-term gains you get for paid support to a commercial product.  What about other companies that release pure open source products with no commercial "safety net" license?  What is their motivation?

  This question I don't have a solid answer to, but here are my suspicions.  Software companies that have released products as OSS have a belief (faith) that by this act, the hordes of new users and products that incorporate said product will generate them more revenue  than if they'd kept it closed.  How can they prove this?  I don't think they can.  But in the end the market will shine some light on the effects of these decisions.  Is Java being used more now that it's been GPL'ed?  Is mobile Java on more phones now that it's open source?  More importantly, is Sun making more money on Java based on it's decision to GPL it? 

  I don't think the market has decided on this either way just yet.  I wish it would, I'm dying to find out.

 

Eclipse/OS X Rant II

Steve and co have done a great job of addressing some of the issues (the ones that were actually relevent to Eclipse) in my previous entry on Eclipse and OS X. One EclipseCON and three weeks later have produced some more information that's probably better as a new post rather than continuing the comment thread.

Issues #1 and #9 has been fixed! I verified in the latest (I2007030313-1051) integration build. The menu fix in particular helps a great deal.

Comments on previous issues:

Item #3. This is an OS X issue. The dialogs don't have hot keys. I envy GTK users, as it looks like all the eclipse dialogs have hotkey mappings. The closest thing on OS X is to Tab to the appropriate button and press space.

Item #4. https://bugs.eclipse.org/bugs/show_bug.cgi?id=177405

Item #5. I agree that with the amount of information surrounding this there is no approach at a solution. And it's highly likely this has nothing to do with SWT. A friend suggested that Apple's JVM could be doing garbage collection differently, and that could be the cause. It does seem to happen more often when there is some sort of File I/O. And it can be pretty bad; locking up for minutes at a time.

Item #7. https://bugs.eclipse.org/bugs/show_bug.cgi?id=177407

Item #8. This is not a browser problem. It's always there, in both the latest integration build and in 3.2.1. But after some comparing with other peoples machines, it looks isolated to me.

Further Issues:

Toolbar Button Disable Image: On the mac the toolbar buttons that are disabled don't change color. At least toolbar bottons that act as combo boxes. In the following image some actions are disabled. I find it difficult to tell.

Combo/Text Boxes: This is a little hard to explain. Text focus is always right justified. Edit a field that has text that is greater than the size of the Combo Box. You cannot see any text to the right without using the mouse to reposition the cursor. This is one that you have to try rather than just see, but here is a control that exhibits the behavior, in the JAR export wizard:

Property Pages: Read-only text fields to not have proper spacing or borders, and sometimes render extra lines that are not the background color. This screenshot is from a property page for a Java project:

Property Pages #2: There is no context menu in read-only controls. You can copy with [Apple] C, but you cannot perform these types of operations via the context menu.

Inconsistencies with layout and widget borders. I think this screenshot speaks for itself. Some things have borders, others do not. Some have scroll bars, others do not. Layout and sizing are inconsistent. Group controls title text is too close to the checkbox above and not close enough to it's client composite (IMHO).

Buttons: Click at the bottom of a button. Nothing happens until about 5 - 10 pixels up.

General Notes: Regarding the overall asthetic value of Eclipse on OS X, some work could be done on how controls and layouts work. Text boxes seem to be the worst offenders. A stroll through the property pages in the Preferences dialog is a good way of seeing this. Overall I'm quite impressed with the response from Eclipse. Open Source is about the community, not the software.

Eclipse/OS X Rant

I recently had a little freakout in response to a blog entry by Wassim Melhem regarding Eclipse on the Mac.  At the time I was getting strange behavior with 3.2.0 on my Macbook Pro.  Eclipse would crash while running a PDE build, runtime workbenches would suddenly disappear, and several other one-time inconsistencies popped up.  Since then I started with a fresh 3.2.1 install and have had no issues.  Regardless, there are some things about Eclipse on the Mac that still bug me, but first, a few disclaimers:

Disclaimer #1 - I'm a big fan of Eclipse.  I am a committer.  I know of many people that work really hard on Eclipse to make it the best IDE it can be.  This post is an attempt on my part to describe exactly what troubles me about Eclipse on OS X, not to piss people off.

Disclaimer #2 - These issues may have nothing to do with Eclipse at all.  Maybe it's Carbon, maybe it's OS X, or maybe it's Apple's Java.  Heck, it could be cosmic rays!  All I know is that Eclipse is the only app I use that feels better on Linux and Windows than on my Mac.

Disclaimer #3 - I'm crazy, I talk to myself, and am a hazard to those around me.

Ok, enough of these stupid disclaimers.  On to the rant:

1. Toolbar icons are too hard to click.  It seems on the Mac that the clickable region of a image button is the non-transparent region.  On Linux it's the whole button, and I'm pretty sure it's the same in Windows.  So this means my brain has to work that much harder to get to one of those little buttons (because each button has a different image).

2. Fonts are too big in the tree views.  Windows and Linux seem to be more concise and at the same time, just as easy to read.  I've played around with other fonts but I can't seem to find anything that works well.  Also, the arrows used to expand and collapse nodes are too hard to click.  It seems the arrows suffer the same problem the toolbar icons have.

3. Modal dialogs!  Where art thou hotkeys!  I've tried every key combination I can think of to try and trigger these dialogs to go away without wasting precious energy to move the mouse.  This is really annoying, mainly because it seems like such a no-brainer.

4. Layout bloopers.  I can't say these are much of a problem really, but I've never seen anything like this on my Ubuntu box at home.  Notice how the tiny text at the bottom bleeds into the resize widget.  And what is that thing after the carrot!?  And notice on the preference page how the default layout doesn't contain enough space for the default preference items.

5. Weird delays.  Saving a file sometimes takes 10 seconds.  Opening an editor sometimes takes 20.  The resource monitor doesn't seem to show any extra load, but Eclipse seems to space-out once or twice a day.  I have 2 Gb of RAM and Eclipse rolls with 512Mb.

6. Speed.  Starting a runtime workbench on comparable hardware is noticeably slower on a Mac.  It just is.  I'm serious.  I've claimed this to people in the past and they blatanly told me I was mistaken.  Can someone make it go faster?

7. Overlapping text editor line decorations.  By default you can have a breakpoint set on a line with a warning and not see the breakpoint.  Those little breakpoints love to hide! 

8. Window painting inconsistencies.  Like a Sasquatch, window refresh problems can jump out of the bushes just long enough to scare you only to disappear before you can get the lens cap off.  Luckily I've captured one on film.  See the white horizontal line to the left?  No?  Look really hard.  And, no, I didn't Photoshop this.

9. Truncated Menus.  I like to scroll as much as the next guy.  But seriously, these menus don't need to be truncated.  I shouldn't have to scroll down manually just because I open a context menu close to the border of my screen.

I imagine most if not all of these issues can be classified as "WONTFIX" because they are probably due to something that Eclipse relies on, such as the JVM or Carbon.  This sort of thing has come up before in bugzillas and the conclusion has always been "don't blame us, go talk to Apple"...or something about the event loop inside of Cocoa.  I'm not a Mac GUI person.  I just want Eclipse to work better on my Mac.  Is that so wrong?

Wall Wart Woes

Ok, going on a trip. Time to pack up the gadgets... Cell phone. (charger). Laptop. (charger). EBook reader (charger). Camera. (Charger). iPod.

What's going here? If you take a look at all the battery charging accessories your consumer electronic devices require, they probably take up as much space/weight as the devices themselves, yet they all perform the exact same function: converting AC current to DC. Why do we need all these things? Can't we just have one that works with everything? If we can standardize on one wall socket type, why not on one AC/DC converter type? Well, the problem seems to be (boringly) hard. Different devices have different power needs. DC is not an efficient way of moving energy. But these problems can be solved.

Of course, none of this is really much of an issue until you need to take a trip. Then your bag is jammed full of these little buggers. They are typically heavy, and poorly designed. They don't fold up, and they don't stack. But an added feature of many wall warts is that the consume power even when they don't necessarily need to. What?! It turns out that manufacturers go with the lowest possible cost adapters they can get. Those adapters are not designed with energy efficiency in mind. This is a big problem, and the EPA has taken notice and created an ENERGY STAR certification program.

So what are some answers? There are alot of good ideas out there: A new DC power standard for the home and office. A standard connector with a physical energy descriptor that could be read by a universal DC power provider. Apple's magnetic connector is great, and they do a good job of making the wall warts egronomic and easy to pack.

Getting back to my backpack, why doesn't the iPod need a charger? All I need is that firewire cable and I hook into my mac and it charges through the data cable. Clever. Why can't my other units do that? They all have data cables...

I think the problem can be taken in steps. The first step, as Brad Templeton suggests, is that for devices that connect to computers via USB, use that juice. Please. Even if it takes longer to charge, I'd prefer that over a dead device. The second step is connector and power standardization. A manufacturer has no incentive to do this, at least not in an open way. Perhaps the EPA can come up with something. Other countries (Chinese and South Korea) have implemented similiar standards. Such a standard would be good for consumers (less wasted power, fewer devices) and good for manufacturers (less to build, less to ship). Once a standard connector and voltage standard is in place, airports, resturants, cafes, hotels, and the like could provide power as additional convienence for customers.

Or, I could just get an iPhone and be done with it.