It's Crunch Time

I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.

It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.

Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.

There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.

I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.

I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.

Anyway, back to bug fixing.

What would the IDE look like if invented today?

I just finished reading a great analysis of Google Wave by Redmonk's Stephen O'Grady. Ever since seeing him present at an Eclipse board/council meeting, I've been following his blog. Highly recommended if you're interested in a great perspective on what's really happening in the enterprise open source world.

As I was reading it, I was struck by what Lars Rasmussen said at the beginning of his keynote on Wave at the Google IO conference: "What would email look like if we set out to invent it today?". Well, apparently they've ended up with an open, extensible framework for hosted collaboration systems that seemlessly merge IM, e-mail, and documents into a single interactive workflow. Wave has really impressed me as a significant step in the evolution in the way we communicate on the web.

Stephen also brought up IBM's Jazz. His analysis at the time was that Jazz is application development given a certain number of technologies that were popular at the time, which wasn't that long ago, i.e., Ajax, Subversion, and IM. And everyone I know who's taken a serious look at Jazz are pretty Jazzed by it.

Today, though, at least from where I sit, there are a few more technologies that could contribute to our software developer toolchest. And I ask, what would the IDE look like if it was invented today, or at least in the next few years, in a world with Google Wave, distributed source control, and smartbooks. Even just seeing David Green's blog on Galileo Builds on your iPhone, an app that shows reports on your Hudson builds, gives a hint at this future.

The world around us is changing dramatically since the rise of the iPhone and competing open smartphone devices and our ability to stay in touch with the Internet wherever we go. Also significant is the rise of web technologies that allow us to leverage that connectivity in better ways. What would an IDE look like in that world? My imagination is running wild ;).

Smartphones, Smartbooks different by necessity?

Boy I'm having fun with Android. Maybe because it's the first time I'm getting the chance (albeit in my spare time) to do some real embedded development. And even in the playing I'm doing, I am experiencing the challenges that regular embedded developers face. Yes, believe or not, even with the latest and greatest hardware, you are limited by the amount of memory and storage your device has, and by the speed and capabilities of the processor. Not to mention power (feel like running your graphics loop at full speed, see how long your battery lasts doing that). You really have to think about these things and write your code carefully to be successful. (And I won't get started on Java again).

One thing you still see in the rumoursphere with Android is the spreading of it's wings into the "smartbook" world. I love that term, Smartbook. Mobile Internet Device is too vague and I think there is a clear delineation between the tree contenders: smartphone, startbook, netbook. Smartphones are the small handheld things we know and love today. Netbooks are the small notebooks which likely have a hard drive in them. But Smartbooks are an exciting middle ground between the two. They have usable screens, 5-9 inches, but everything else is like a smartphone, particularly in mobility and power consumption. A good smartbook should last the day without charging making it handy for carrying around conferences like EclipseCon, for example :).

I'm not sure Android can scale to the big screen, so I've been looking around at the alternatives and Moblin in particular. I can see myself becoming a big fan of Moblin development. It's much more like a traditional Linux environment and has my favourite packages available, including Qt, GTK, and X/OpenGL. But I wonder if Moblin has scalability issues the otherway. All those great packages take a lot of resources and they certainly won't fit on the 256MB NAND flash chip on my Dream phone. And I don't see consumers being happy losing even more battery life to support bigger and faster chips. So in the grand scheme of things, it appears to me that it requires us to have different software platforms to match the hardware. But we'll see if the Moblin guys manage to get running on a smartphone.

That's lead me to wonder if the same is true with the applications. It's pretty obvious that smartphone and desktop apps have to be different. Screen size and the rest of the resource constraints on phones force you to design the app differently. Now is the same true for Smartbooks? Is this a third category? I have a feeling yes. You may have a bigger screen size and it may look like notebook, but the resource constraints are still there. You still need to be worried about power consumption and you won't have a desktop class processor to get you out of trouble with sloppy algorithms. Mind you, that's just good development practice anyway. I'll have to think about this a bit more.

At the very least, you have a different development environment for your smartbook apps. Generally you'd have a cross compiler, even if it is the same processor. It helps keep the environments separate from the rest of your development desktop. Mind you Moblin seems to be going to great lengths to avoid that for some reason using VMs and remote builds. Cross compilers aren't that scary, you know :). And the CDT does a great job working with them.

Fighting for Mobile Mindshare

The more I look into what's happening in the mobile scene, the more excited I get. The smartphone platforms really are the computers of tomorrow. They all have big (enough) screens with touch, most of them have keyboards, connectivity is excellent with both wifi and high speed 3G (Rogers in Canada says it has 3.5G, even better). Heck, they're way more powerful than the PCs we fell in love with in the 80s.

I'm looking at this from an application developer's point of view. If you're a mobile app developer and you have a great idea, what platform do you target? And it's a pretty significant choice, just like it was in the 80's. All of the platforms have not only different APIs, but different programming languages. iPhone with Objective-C, Android with it's own version of Java, Palm Pre with JavaScript, RIM with J2ME, and Nokia with almost everything including Flash and C++. And then you have the Linux-based MIDs such as Moblin (need to mention my upcoming new bosses :)) and Maemo which are also starting to blur the line as they start acquiring 3G functionality. In theory, you'd love to get your idea on all these platforms.

But I'm really not sure how this is supposed to happen and that's one of the biggest challenges we have in the mobile market. I can see why these vendors want to keep their own identity. These SDKs are differentiating right now, at least until we get more apps in place. And they are fighting for the same market and would rather see developers build apps for their platform and not the other guys. So, I think it's up to the app developers to solve this, to give them bigger markets to sell into. We'll see how it pans out.

The good news is that, thanks to Eclipse, there is already a number of these vendors who have tooling based on Eclipse. Theoretically, you should be able to build an IDE that integrates all these tools together and least have a common development environment. And the Eclipse Pulsar mobile working group is working on making it easier to set this up.

There are some common technologies. I think all the platforms have Web Browsers that support Web 2.0 applications (and that's all Palm Pre seems to have). And since they all have full-time connectivity to the Internet, this seems like a reasonable choice. Also the newer platforms have 3D graphic support through the standard OpenGL ES API. That might be a good choice if you have a more graphics intensive application.

The one thing that crossed my mind is whether modeling has something to offer. People who know me will find that funny as I'm quite jaded from my days working on modeling tools. But Model Driven Development was intended to address this kind of problem. I think the biggest problem with MDD was poor modeling of behavior, a must in this domain, but you can't dismiss the potential of writing your app in a platform independent language and generating the implementations for each platform you want to support. Whoever comes up with that, and it'll be immensely expensive to build, will have a market of confused application developers to sell to.

Fun with Qemu/Qt

Just for fun (and maybe profit), I thought I'd try and get Qt running on the mini ARM Linux setup that I used for my tutorial at EclipseCon. Low and behold, all I had to do was build it with the compiler I got from CodeSourcery for ARM and it worked!

Now there isn't a whole lot of magic here. It's using the Linux framebuffer device that draws to the screen. I'm not sure how it would look on a real device but it looked might fine on qemu. Here's a snapshot of it running on my laptop, which is now solidly Fedora. It's running the browser demo app and has loaded my blog just before I posted this. It took a little while to load and render, but again, it looked pretty good.



Having gotten this far, I start to wonder how much better it would be if I had OpenGL ES emulation in qemu. Would it be faster? Curiosity might kill this cat...

WolfenQt: Proof in pudding

An update to my previous post. As proof I got it working, here's my blog from earlier today. You can't see the flash since apparently the adobe flash player bypasses the widget set and opens a native window directly. Wonder where it showed up... At any rate, lots of fun. And with OpenGL mode turned on, performs quite nicely and the widgets are quite readable. Click on the picture to see full size. Very nice.

Widgets in 3D: WolfenQt

As the shiny balls spin around in my world, Qt has jumped back into the foreground. My Fedora laptop is busy building 4.5 as I write this and slowly catching on fire (man these things get hot when they're busy working). While that was going on, I took another look at how you'd implement Qt widgets in 3D space, kind of like Clutter does in a GTK fashion (mind you I think those are just static 2D images, not widgets).

Low and behold, I came across the Qt Lab Blog entry by someone there who actually has a demo of Qt widgets running in a maze similar to the old id games. He called it WolfenQt. Take a look here:



Very cool! This is exactly how I was hoping it would look and feel. And Qt has the framework to make it happen. I need to do some experimentation with it once I my 4.5 compiled to see how much of this is done in OpenGL versus software rendering. Looking at the code it looks like quite a mix of both. But from the video, it looks fast enough. And I do know the marching guy is rendered using OpenGL at least.

This is the kind of innovation I'd love to see. We talk a lot in the Eclipse world about Java thick clients and Browser/Server architectures. But there's still so much more you can do using native APIs that take advantage of all the new hardware acceleration capabilities that today's platform providers are giving us.

And the CDT is such a natural IDE for this new world. With all these new platforms, developers really need a cross platform cross target development environment to work with them all. The goal for my CDT work right now is to show that off and put together IDE packages, like Wascana and maybe something with DSDP for embedded, that can be used in these environments.

Putting on my Fedora

Well, I did it, I finally did it. I ordered a 320GB drive and set up a dual boot situation with my old Windows install and my spanking brand new Fedora 10 on the rest of the disk. So far so good. It wasn't a perfect process, including a 4 hour shrink of my NTFS partition. But I'm up and running. And I have an out to go back if things go bad, but I have a feeling I won't.

I have a Dell D830 and had to install the Broadcom wireless driver and the nVidia driver for my NVS 140M graphics chip. Now, since these aren't under open source licenses, you have to get them from other sources, in my case rpmfusion.org. This is part of what sets Fedora apart from Ubuntu. With Ubuntu, it's a lot easier to set this up. You know you can mix GPL and !GPL and it's OK ;). At any rate, I deal with it since I feel Fedora is a bit crisper, especially for those of us who think they know what they're doing.

So why would I bother doing this? With Eclipse, Windows is a pretty fine development environment. The command line environments there are abysmal, but that's why we work hard on ensuring that you can do all your work from inside Eclipse. But that's probably it. I want to get back into an environment where command line is king (I used HP and Sun workstations long before becoming a Windows developer) and get a better feeling for what development life is like there. That and as I've mentioned before here, Linux is just the best environment for building embedded Linux platforms which is my hobby as of late.

Anyway, we'll see how long I last here before running back to Windows. As I have it, it's not too far away just in case, just over there on /dev/sda1 and in a VM coming soon.

EclipseCon notes and git

Well, I'm back at my day job at Wind and am doing a little reflection on what happened last week at EclipseCon. Despite the rumored lower attendence, I met with pretty much as many people as I do every year, maybe even slightly more. And hopefully that'll translate into growth in the CDT community.

And I guess my talk on building communities was a little over the top on the subject of project "takers" that I had a number of people come up to me and apologize and offer to contribute in the future. I certainly didn't mean to offend or criticize. I just wanted to prepare project contributors that there are vendors and people who are happy to take your work for free and not give anything back. And, while that's frustrating, with open source licensing there's nothing you can really do about it but be mentally prepared to see it happen.

The one area where I saw a very interesting rise in momentum was with distributed version control at Eclipse and git in particular. It started with discussions at the councils on Sunday where it became obvious that we need significant community interest and willingness of the projects to drive this home to justify the significant cost to the Foundation. There were a couple of BOFs and panels that I missed but it sounds from Karl's post that the activity was significant enough for the Foundation to start putting a plan together. Very cool!

The more I talk to people and dig into it, I think git and DVCS in general is probably one of the most significant technologies driving change in the way we work on software development projects since objects invaded our world. As evidence of that, the thought of distributed source repositories opens the door to the IDE in the Cloud. The Cloud could be built around git repos and if I need to work disconnected, or work with command line tools, I just clone it onto my laptop and merge back later. And being the old "curmudgeon" C/C++ embedded tools guy, that's a significant admission...