Mobile will drive "IDE in the Cloud"

I'm in the middle of making some last minute code changes for work before I start my vacation, or staycation as I hear lots of people calling it these days. We have a pretty big JUnit regression suite to test our p2-based installer, and I made the mistake earlier this week of not running it and ended up having to rewrite the algorithm to solve scalability issues. Lesson of the day, don't create too many Java objects in long running native code, Lord knows when they get garbage collected.

This mobile machine's hot, man!

The main reason I didn't run them was because I was working at home with my laptop that day. These long running tests create some massive heat build up in my machine. I lost a hard drive a few years ago doing something like that and it's made me nervous ever since. I really don't think laptops are built to handle the intensive compute and disk workloads that I need as a software developer. I think I'm pushing the envelope too far. In fact, I was going to start this blog while the tests were running earlier this evening but the heat knocked out my wireless.

The ultimate mobile developer platform?

I'm sure you've all been following the Chrome OS "shiny object of the week". The technical details of the OS itself and the supposedly sinister plot by Google behind it aside, there is no doubting that the designs for the upcoming sub-netbook, aka smartbook, machines are pretty exciting. All day battery life, integrated 3G or WiMAX connectivity anywhere, and with big enough screens to actually be useful. And, yeah, looking at the processors that allow you to do that, you aren't running Eclipse and gcc on these things to any great scale. But I'd love to use one of these things around the house or on trips to write code with. Especially if it lets these burn marks on my legs heal ;)

Mobile will drive IDE in the Cloud

So assuming you want to write software using a mobile device, how would you do it? And, you know, after all the naysaying I did about "IDE in the Cloud" at EcilpseCon, I finally get it. Wouldn't it make sense to have a workstation setup where you keep all your development tools and do your builds and run your tests, and then be able to access that all from a web browser anywhere in the world? from any mobile device in the world?

That flexibility will drive demand for this architecture, for similar reasons we used this architecture in the pre 1990's where we used to have dumb terminals connected to powerful DEC VAXen (at least they were powerful for the time). What we're talking about isn't much different than that, only the terminals, i.e. the mobile devices, are a bit smarter. But then the compute servers are probably equivalently faster if not more so.

An opportunity to simplify

And, yes, we do use VNC and other remote desktop protocols and clients to accomplish this today. And maybe you can so something similar in a browser (in fact I know you can, ever see WebHuddle?). But with these things I think you'll run into the screen size issue. Myself and a lot of my Eclipse community colleagues have presented Eclipse on 1024x768 projectors and it's brutal. The IDE just doesn't scale that small to be useful. But this is the screen sizes you have to deal with on mobile devices.

While working through this new architecture and solving that problem, I think it's also a great opportunity to simplify the IDE. New users find Eclipse overwhelming with all the views and toolbar buttons and menus, it's really tough to know what to do next once you fire it up. Being in a browser opens the door to new ways of working. I think we're still trying to figure out how to do content creation via a browser, and from Google Apps and Microsoft's upcoming web-based Office suite, we'll learn a lot and maybe some of these things can be applied to software development.

Is it time for a new platform?

Mobile is driving a lot of change in the software and device world. I really believe the software developer will be able to benefit from it. But I wonder whether the platform we've built with Eclipse is the right vehicle for this. I know the IBM team is scrambling with e4 to address that. But I'd like to see real innovation here, something that breaks away from the old desktop IDE paradigms of the past. Maybe Eclipse's "Black Swan" is out there. If it is, we'll have to make sure we recognize it and welcome it to the community.

Android versus Chrome OS in Netbooks?

Just a quick one. There were a lot of rumours about Android running on laptops, with Acer especially. Now they're wondering if Chrome OS wills squash those plans. People, Android was never meant to run on netbooks. You are worrying about something that was never going to happen in the first place.

If you ever watch the Android UI presentations at Google IO, they pretty much confirm that. At one point one of the designers commented that Android developers need to deal with screens with more pixels, but to deal with that by checking density, not physical screen size.

All Android apps are being built assuming a 4" screen. It would suck if you try to stretch an android list widget to a 10" netbook screen. Big screens isn't what Android is about.

Update: I just read that Schmidt and friends just mentioned the two projects working closer together in the future. Chrome on Androids Linux/BSD OS but without the Java based UI and the Dalvik VM that drives it makes sense to me.

More Thoughts on Chrome OS

As quickly as it came, the hype has died down over Google's announced Chrome OS. There hasn't been much to stoke the fire so it's died down naturally. And that's a good thing. There's a lot of lead time to figure out how we all fit into this story, if we want to fit in at all. Here are a couple of more thoughts that came to me as I read all the stories. BTW, it seems some writers have already played with the OS, or they're making a lot of assumptions...

Equinox as a local app server

One of the coolest features of OSGi and the Equinox/Jetty implementation at Eclipse is as an app server. This is something I've always wanted to spend more time with. I don't think Chrome OS will be successful without some means of running local applications and the marriage between Equinox and the Chrome browser is a natural. I'd hope the two of these groups are talking.

GWT or SWT browser edition?

To be honest, I'm a neophite when it comes to what's happing with running Eclipse in browser mode, be it RAP or the new e4 SWT browser stuff. All I've seen are demos that try to make the browser look like a desktop app. I think that's doomed to failure. The more you make it look like a desktop app, the more users are going to expect it to work the same as a desktop app, and that just isn't going to happen.

I'd take this opportunity to reinvent my application's UI, to break away from the paradigms that the desktop has locked us into and to come up with cleaner, more workflow driven UIs. Having good tooling is still a must. The Google Wave guys were quick to pour praise on GWT which they used to build the Wave app. I'd pick that if I were starting down this road.

Is there a role for native in Chrome OS?

Believe or not, I think the answer is yes. We'll I'm sure you believe that I think that but anyway. Chrome supports the NPAPI native plug-in API that was started by Netscape/Mozilla/Firefox and is now supported by WebKit/Chrome/Safari and Opera. If you have the need for a high performance app that does it's own rendering, like a game say, then NPAPI is for you. Google already does this for it's O3D graphic rendering API. You can too.

Now, what you can also do with NPAPI is present your C++ objects for JavaScript scripting in the browser using this interface. Now didn't Dave Thomas say something about C++ and JavaScript being the future in his Eclipse Summit Europe keynote last year?

ARM versus Intel

It's not a secret that Intel has an offer to purchase my employer, Wind River, on the table. That hasn't closed yet. But I have to agree with the analysts who see this will help ARM and it's partners. More interesting, though, is that this will really be the first time that ARM platforms and Intel platforms will be running the exact same software platform. It'll be pretty easy to see who's netbook/smartbook/mobile solutions are better. More importantly, it'll drive both of them to raise the bar, which at the end of the day benefits the consumer like good healthy competition does.

Google Chrome OS

Google announced it's initiative to build an OS around it's Chrome browser. About time. The idea of having a browser based Linux platform is one of the things that had driven me to play with Linux in the first place. It was clear from the experiments I did that this was easily possible. Webkit with a good JavaScript engine is a great choice for that, which is what Chrome is. I guess it just took Google's might to make it happen.

So why would Google invest in something like the Chrome OS. It's easy, and people have speculated on it for a long time. Google wants you to spend all your time in a browser. Why? Because it changes the game. Commerce has move to the web in droves and Google wants to get you closer to that so it can get it's cut for getting you there. It's been a long time coming and the planets are finally aligning to make it happen.

Firefox could have done the same, but Google has the dough to make something like this happen. Which again calls into question why this couldn't have been done in an open source project to start with. But I fear the Gnome/KDE bun fight has taken the Linux community's focus away from how the desktop is really evolving. Google knows where things are going. It's helping to drive them to begin with.

Will this impact Windows? I don't think so. We're creatures of habit and Windows already has a good browser experience. Will this impact Linux desktop? Probably. At the least it could be a better place to go if all you want to do is get away from Microsoft, which, if you are Joe average consumer, would be the only reason you go to Linux. Mind you this Joe developer is pretty happy on Linux. Even then, I am sceptically waiting to see a good browser based IDE experience.

But is the web ready for this? I'm not sure. A lot of people are saying Google Docs is pretty good. GMail is my e-mail client of choice outside of work. I could IM using the browser I guess. I think Google Wave will shake the cart here providing a slick collaboration environment that redefines all these things, so we'll see. I'm sure once you adopt a browser-based OS you'll find out quickly whether it sucks or not.

So what does this mean for Android? As I've stated here and on Twitter (dougschaefer, BTW), browsing on a 4" screen blows. I really struggle with trying to pan around a web page to find the information I need. This is not to say that web services aren't useful on smartphones, it just that they work much nicer if there is a thicker client to format the data to the platform, and to just manage the data bandwidth better.

Probably the most interesting aspect of this that crossed my mind is that the Palm Pre already is browser based OS. It's also based on Webkit running on a Linux platform. So the real question is - will Google try to get Chrome OS into the smartphone format? I swear the Chrome and the Android guys don't talk to each other. Or this strategy would already be figured out before the announcement.

Qt, Box2D, and other random musings

First of all, I'm very jealous of the Linux Desktop gang for holding their summit in the Canary Islands. I did a quick look at the cost and it's not any more than what I spent to go to Stuttgart for Eclipse Summit Europe. I can't wait to hear how it really was.

At that Summit, Nokia announced that they were moving from GTK to Qt for their Meamo Linux distribution for their handheld/tablet type devices. They were upfront about the reasons and it makes perfect sense. The plan is to have Qt as the default toolkit for Symbian devices as well. Learn one API and target them all. This is exactly what I hoped would happen with the Trolltech acquisition. So kudos to Nokia for a smart move.

And I hope through the Intel partnership with Nokia this will spread to Moblin too. For app developers, I think it's really critical that we see some consolidation on the number of mobile Linux platforms. The nightmare I see supporting all the different Linux distros in my day job doesn't need to be reproduced for mobile.

Anyway, that got me thinking again about Qt for my hobby activities. I want to learn what it takes to make games for mobile handsets and what kind of things the CDT would need to better support that. Having your work run on both mobile and in a simulation mode on the desktop makes a lot of sense, and one of the main drivers I see behind Windows adoption of the CDT. Qt would be a great framework for this for a few reasons. First you can target Windows and Linux desktop for simulation environments and the growing number of mobile platforms adopting Qt. And for me, Qt's QGLWidget and Android's GLSurfaceView work almost identically, further supporting my cross platform efforts. I'll have to peak at the iPhone SDK and see if that holds true there too.

Speaking of gaming on mobile. Most of the games I see there are actually 2D games. There are probably a few reasons for that, but 2D games are just easier to do. There's less pressure to actually simulate reality as you get with 3D. To help with 2D game development, a couple of guys in the Android community have ported the C++ Box2D physics engine to Androids NDK (Native Development Kit). Looking at all the cool 2D things I see on the iPhone and given the BSD nature of Box2D's license, I can imagine its driving a lot of them. And the results are pretty cool, especially if you hook up the accelerometer on these platforms. I'll have to play with it and see how easy it is to use.

MinGW on Linux on Windows 7???

My Windows/Linux world has gotten a whole lot more complicated in the last few days, but I'm really liking how it's set up now.

As I mentioned in my blog entry on multi-target Makefiles, I am using Fedora 11's mingw cross compiler along with gcc's multilib support and am building the little C++ project I'm working on at work for both 32 and 64-bit Linux as well as Windows all in the same Makefile and all on every build of my CDT project. That is extremely handy and I've already fixed a problem early where there is a mismatch between the linux and mingw environments, no strndup on mingw, and was able to do so without switching machines.

This is awesome and I'll be able to produce executables for all three of these platforms for testing all in one shot. Kudos to the Fedora folk for providing first class support for mingw cross compilation and not ignoring the fact that us developers still need to target Windows once in a while. That makes Fedora my favorite development environment by far.

But, alas, Linux drivers suck for laptops. I have a Dell and a port replicator at work and at home. I have a 24" monitor at work running at 1900 wide and a 22" monitor at home at 1680 wide. I swap between the two every day, and often work undocked at home with no external monitor. I could never get Linux to recognize when I dock and to figure out which monitor was hooked up. That drove me nuts.

A couple of things have also happened recently. I've been testing the Windows 7 RC on a separate partition and have started to really like it. As a lot of people have mentioned already, it's what Vista should have been. It doesn't quite have the flash of the Mac, but I find it's a great balance between flash and the stability of XP.

The other thing that happened was that VirtualBox 3.0 has been released and it now has OpenGL support for both Windows and Linux guests. That was one of the reasons I moved to Linux, to experiment with OpenGL there. Now I can do that in a guest OS.

So putting all that together, I've replaces OSes yet again (been doing that regularly for years it seems). I'm now running on 64-bit Windows 7 with two major VMs, one for my fabulous Fedora dev environment, and one for the corporate XP environment I used to have there for Outlook and Netmeeting. So far so good. I get the odd glitch once in a while but nothing I can't recover from and it is a release candidate. But now I have the best of all worlds. Except maybe MacOSX, and an iPhone dev environment. So close...

Understanding the Mobile Killer App

Clearly, with the success of iPhone and Blackberry and the buzz around Android and Pre, mobile already has its killer apps. But for someone new like me to this arena, I find it important that I try to understand what that app is and simplify the category so I can know where to focus what little time I have to play here. So this is what I've come up with, and I hope you have an opinion you can share in the comments to help guide me.

Here we go. I actually think there are two killer apps happening in the smartphone market today. (I'll leave out the *book platforms for another post as that's starting to gel in my mind as well). Start by looking at the iPhone, including the iPod Touch. It's really Entertainment apps that have made the iPhone one of the most popular mobile platforms of our time. My son has a Touch. He has his mp3's there, he watches YouTube videos there, he plays games on it. It's probably what the PSP should have been if it had downloadable content. The platform pretty much comes with good multimedia apps, so if you want to make a hit, writing a good game is the place to start. And looking at most of the other platforms, especially the ones with 3D hardware acceleration, this is true across the board. Actually, you look at the real big picture, good games are popular on all computing platforms, even Spacewar! on the PDP-1.

The other killer app is something a we talk lot about in the Eclipse community, especially my enterprise brethren. And that is thin web client apps. This is most obvious on the Blackberries that almost all business managers have today. Accessing e-mail from an exchange server on a small screen requires specialized software to ensure a good user experience. But I really think it goes beyond just e-mail. There are a lot of web services available in web browsers today. But web browsing on the small screen still sucks and likely will always suck. Writing a thin client that can present information from the web in a format suitable for the form factor is a real winner. The top Android apps I use are clients for gmail, twitter, and RSS. I'd love a good app that lets me write this blog, but I haven't found one yet. But I know the Google provides the API to do it and Twitter has a good API. Wrap those together and you got a customer. Or maybe I should be the developer ;).

Of course, now I'm torn. I've always dreamed of making games, but never had the opportunity to do it. I know it's a lot of work and probably something I couldn't do well in my spare time. I'm also pumped by the "mash-up" possibilities writing thin clients for internet apps. And that's probably something I can do more quickly. Lots of fun. And a reason why I think the industry is going through a reinvigoration. Where the killer app for the desktop has come and the shine has gone (that killer app was office apps, browsers, IDEs, and games by the way). There's an opportunity to get in on the ground floor of the new generation.

Android NDK Release 1 is Out

I got a surprise today (aside from the passing of Michael Jackson), the Android Native Development Kit (NDK) team has put out its first release. They never really hinted on their mailing list this was about to happen, nor did they actually provide a real time line. But it's a good surprise.

The purpose of the NDK is to provide the ability to write native libraries that the Dalvik Java code can call through the Java Native Interface (JNI). This is the exact same interface we're used to with desktop JNI so it's quick to use. As I've mentioned here before, writing native code allows you to take advantage of the underlying hardware that Java hides from you. In this first release, it's pretty basic, exposing only a few basic APIs such as the standard libc C run-time library, the math library, and libz for accessing compressed files. Just enough to accelerate some of your algorithms with direct execution by the CPU, which is ARM only right now.

There is still a lot missing, and they have promised there is more to come. OpenGL ES and audio are the big items on my wish list. At least I have enough information to be able to set up OpenGL ES so that it'll run on my HTC Dream phone and the emulator. But there are no guarantees it will run on any of the upcoming phones since the ABI hasn't been locked down. The GLES shared library name is the biggy (e.g. PowerVR as seen on the TI OMAP chips names their libs differently) although the header files should be the same.

The build system, though, has me very concerned. They've taken a lot of the concepts from the Android platform build system, which builds everything in one tree, and brought it to the NDK, including the restriction that everything has to be in one tree. I don't build software like that. I put my native code in the same Eclipse project directory as the Java. I'm also working on a library that I want to use in a number of different platforms as mentioned in my previous entry. Android is just one target, it's not the center of the universe.

I also noticed this when I took a look at Moblin. There is a standard way you setup a gcc cross-development environment. GCC has the facility to define a sysroot that organizes include files, and libraries in a natural way. And that allows for multi-target projects with very little change to your makefiles. Don't assume you're the only build system that wants to build my code.

One final nit, the Windows toolchain was built using Cygwin. Cygwin is a Linux emulation environment for Windows. As such it tries to hide as much of the Windows environment as it can, in particular when dealing with file paths. That messes up the CDT. We have some code that tries to deal with that, but the architecture is poor and we may loose that functionality over time. I'm a big fan of CodeSourcery and these guys are masters at building toolchains for multiple targets and run cleanly on Windows without Cygwin. Mind you, I'm pretty much solely on Linux now so that doesn't matter to me as much any more. But others in the community will care.

Anyway, besides all that, it's a great start. Native development and standard native APIs will be a key success factor for Android. We saw in the game console market how important it was for game developers to be able to target multiple platforms. That larger market allows for larger budgets which, of course, allows for better apps. The Apple guys get that and the iPhone SDK is very good, and at least for 3D Graphics and Audio, very standard. John Carmack of id (Doom and Quake) is a huge fan of theirs, but I wouldn't mind seeing Doom titles running on my Android phone.

CDT 6.0 Leaves the Station

CDT 6.0 is out. Come and get it!

As I posted on the cdt-dev list the other day to the CDT developers, "CDT 6 has reached all expectations I've ever had for the CDT and for that I'm proud of you all." And I mean that. The biggest new feature for me is CDT 6's new ability to find header files pretty much anywhere in your workspace. With that, the CDT search and code navigation features work almost all the time, even on code that you simply import even without makefiles. I've been using it a lot on projects like that and I continue to be amazed and proud of how well it works. It's been a great group of people who've worked on indexing over the years and after 6+ years, I can finally call it a success!

There are a few other new features that are also very handy in CDT 6. The New and Noteworthy is on our wiki at: http://wiki.eclipse.org/CDT/User/NewIn60. Feel free to take a look and try them out. The quality of CDT 6 is also very good. As the pace of new feature development for CDT has slowed over the last couple of years, we've gained in robustness so I'm proud of that as well. As I did with CDT 5.0, I can recommend using the 6.0.0 release in production, something that I wouldn't have in releases before that.

As I look over the last year or so and look to the future, I see my involvement in the CDT has taken a real hit. I do not see myself working on any big features for the CDT in the forseeable future, as I haven't really in quite a while either. That's just the reality of where I am right now and I'm OK with that. The CDT is in fine shape. Yes, there are some areas that people want to fix up, scanner discovery being at the top of that list, and I will help guide them as they need my help. But I'm going to transition my role into a CDT user who wants to contribute to make the workflows I use better. And hopefully, others will find that useful as well.

It's been a great ride with the CDT and I'm not ready to jump off yet. But there are other interesting rides that could use my attention, Android development being my personal interest area. And if you can't tell from my recent blog posts and tweets, I've been totally re-energized by what's happening in the mobile space. And, trust me, that's a good thing.

Multi-target Makefiles

I learned a really cool trick with gnu make the other day. I've started work on a little game engine based on OpenGL and OpenGL ES targetting Android (of course), the PowerVR simulator for ES 1.1 and 2.0, as well as Linux and Windows desktops. When I first set up the Makefile, I had five different target binaries and I hooked it into the CDT as a Makefile project with five different configs that called make with the right target. Worked fine.

But switching back and forth between each of the configs in order to test an idea was a pain. The CDT does have a Build All Configs menu item but it's a pain to fire that up since it's like three levels deep. I got to digging around the gnu make manual in hopes that something would jump out and bite me to make things simpler. And, it did!

Gnu make has a couple of interesting features that help. One, you can create a multi-line macros that take parameters (define ... endef) much like the C preprocessor. You can then call 'eval' on the resulting string to have that string parsed into the Makefile. That's awesome on it's own. But, the second great feature is the ability to define variables on a per target basis. That allows you, for example, to have different CFLAGS settings for different targets.

So combining these features, I've been able to set up my builds to generate my library in five subdirectories under lib and objects under obj, all from the same sources. I tried this with a native app at work and I've also figured out how to add target specific sources to the mix. What a lifesaver.

Unfortunately, there are gotchas in CDT-land. With each source file compiled by five different compiler and option combinations, it gets pretty confused about what's what. But the guesses it's making aren't so bad and it really drives you to keep the target specifics to a minimum.

To give you an idea of what it looks like, here is the relavent fragment from the makefile for my engine right now. I also just noticed the nice way it does source/header file dependencies using -MD of the gcc compiler and gnu make's include. Now if I can get the CDT to generate me a SOURCES list automatically...

all: android pvr11lx pvr20lx linux mingw

define PLATFORM_rules
$(1)_OBJS = $$(SOURCES:src/%.cpp=obj/$(1)/%.o)
$(1)_LIB = lib/$(1)/libdasEngine.a

$(1): $$($(1)_LIB)

$$($(1)_LIB): $$($(1)_OBJS)
 @mkdir -p lib/$(1)
 $$(TOOL_PREFIX)ar rc $$@ $$^

obj/$(1)/%.o: src/%.cpp
 @mkdir -p obj/$(1)
 $$(TOOL_PREFIX)g++ $$(CFLAGS) -DDAS_PLATFORM_$(1) -MD -o $$@ -c $$< 

-include $$($(1)_OBJS:%.o=%.d)
endef

android: TOOL_PREFIX = arm-none-eabi-
android: CFLAGS += $(ANDROID_INCLUDE) -DANDROID -fno-exceptions -fno-rtti
android: $(eval $(call PLATFORM_rules,android)) 

pvr11lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/1.1/include
pvr11lx: $(eval $(call PLATFORM_rules,pvr11lx))

pvr20lx: CFLAGS += -m32 -I$(HOME)/gl/powervr/2.0/include
pvr20lx: $(eval $(call PLATFORM_rules,pvr20lx))

linux:  $(eval $(call PLATFORM_rules,linux))

mingw:  TOOL_PREFIX = i686-pc-mingw32-
mingw:  $(eval $(call PLATFORM_rules,mingw))

Palm, doing open source right

I found this in a roundabout way through the Beagleboard.org blog. Palm has recently started up an open source license compliance program. They have a team that oversees it and have set up a web site, http://opensource.palm.com, where they are releasing the open source packages they used and the modifications. See, is that so hard? Well it is a significant amount of work to set something like this up, but you are getting a ship load of great software for free, so it's well worth it and by sharing your modifications really shows you as a good open source citizen.

There's been so much FUD spread over GPL and LGPL, especially LGPL. Linux wouldn't exist without these licenses. And Linux-based platforms, like the Palm Pre and Android, wouldn't be possible without them either. Neither would a fully open Eclipse CDT-based IDE for MinGW Windows, which due to the anti-GPL rules of Eclipse, there isn't. But, enough griping about that.

Palm looks like it has a hit on its hands with the Pre. I'm still awaiting to see what their SDK looks like. So far, it looks like a bunch of Javascript, much like Android is with Java. I'm currently looking at these platforms with an eye on gaming. The Pre certainly has the hardware for it. Even my little Android phone draws a mean triangle. But you need access to that hardware to get good frame rates, which for me means native code, of course.

Android at the Ottawa Demo Camp

Well, my demo at Thursday night's Ottawa Eclipse Demo Camp was a mitigated disaster. My laptop is in power hell as the batteries last only a few minutes and, of course, started to run out during the demo. The USB connection to may Android phone didn't work and we theorized that laptop shut down the USB connections due to lack of power. So I couldn't show that. I also ran out of time which I had a feeling would happen and I forgot to add a line of code that would have prevented the app from crashing.

Aside from that, I hopefully got my point across. Eclipse is a great IDE for doing Android development. The Java side is a natural and you get all the advantages of the JDT with the target management provided by the Android plug-ins. I also showed how easy it was to set up the CDT to write native methods in your Android apps. While not officially supported, there is an Android NDK (Native Development Kit) project that is under way to provide that support in an upcoming SDK release (donut I believe).

What I didn't get to show was the two implementations of Android's Kube demo, which shows a Rubik's cube spinning around apparently trying to solve itself (being purely random, I'm sure it'll solve itself just after the monkeys write that novel). It's not a complex 3d object, with only around 3000 triangles (300 drawn 10 times per frame to give it some load), but the performance gained by writing the transformation matrix math in C++ versus Java brought the framerate from 25 frames per second to 36. That's pretty significant. And on a mobile device where every CPU cycle drains a little bit of the battery, doing more with less is a key factor to a successful product.

At any rate, I had a great time that night. I got to catch up with some old buddies that I used to work at QNX with who are now doing a start-up just down the road from our Wind River offices. And there were some old buddies there from my ObjectTime days there as well. For some reason, these Eclipse events bring us all back together. It's probably because Eclipse is huge in Ottawa. If your a tools developer here, there's a pretty good chance your involved with it. And there are some pretty good tools developers here.

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.

Living with a Dream, an HTC Dream

I realized that I haven't blogged since I went out and bought my new HTC Dream Android phone from the local Rogers shop. I guess that makes sense since I've been busy when I had free time in the evenings and weekends playing with it. First, I had to figure out how to get the Android tooling to hook up to it via the USB cable. Then I went about getting applications running on it and downloading things from the Android market (currently Rogers only has free apps, which is probably OK for now).

The first app I wrote was a stopwatch app that uses the sensors so I can tilt it to start and stop it, something I can use to time curling rocks in the winter. But there are lots of stopwatches out there so it's probably not worth going through the effort to get it up on the market. But it was awesome to get into that mindset of a mobile application developer. I've been doing tools for quite a while. If you want to build good tools, you really need to get into the mindset of your customers. But then, that's true of all product development.

Of course, I'm using Eclipse to build these apps. There are a couple of things that bug me about the Android plug-ins, including their insistence you set the SDK location preference, even if you don't have Android projects in your workspace. I'm also using the CDT to work on native apps using the upcoming Android NDK (native development kit) for native libraries. And I've already blogged about how mixing JDT and CDT natures in the same project pretty much makes the Project Explorer unusable. I've also added egit to the mix as I store the code on a little Linux server I have at home, and egit is still has a way to go to be ready for prime time. Having said all that the IDE is definitely usable and I'd hate to have to do this stuff without it.

So my next step is to try and figure out what makes a good mobile app. The power of these little machines makes anything possible. Their connectivity with wifi and 3G opens the door to great internet apps. I'd like to see the bluetooth connectivity (once they release Android's Bluetooth API) used to connect to peripherals and other devices. And, of course, the HTC phones have 3D hardware acceleration (despite not having hardware floating point, but that's typical I hear), making it possible to do some neat little games. The possibilities are endless, you just need to figure out what people want to do on these platforms.

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.

Android Hype Machine in Full Gear

If you are following the news on Android lately you'll wonder what the heck is going on. Soon, you'll be seeing Android not only running on your smartphone and netbook and smartbook and netphone, but maybe your grandmother too. OK, maybe not your grandmother. But with Acer's announcement that they are releasing an Android notebook in the third quarter this year, a real announcement, not just the rumours that we've been hearing for months now, Android is starting to spread it's wings.

I really wonder, though, why that is. Why has Android turned into a hype machine as of late? Google expects 18 new phones out over the next year, and they gave everyone who attended the recent Google IO developers conference a free HTC Magic developer phone (wish I was there :( ). The timing of all these announcements shows me that Google really has a pretty active marketing department, even if they seem to be behind the scenes, and even as the face of Google always seems to be their engineers.

Anyway, if you're writing an Android app, check the screen size on start up and change the layouts accordingly to support all these form factors. And if you're writing native code, get ready to recompile for x86 as well as ARM. Oh, and apparently MIPS is now in the mix thanks to RMI and Embedded Alley. I'm not sure whether the hype will continue to grow and whether the consumer excitement will match, but it'll be interesting to watch.

BTW, I always wondered why vendors list Android and Linux, isn't Android a version of Linux? Well, actually no it isn't. Sure the kernel and the drivers are based on the Linux kernel and drivers. But user mode is very different, and for a reason we at Eclipse are quite used to. The Android team is avoiding GPL and LGPL like the plague. It makes sense as it allows for vendors to make custom versions of the libraries as they see the need. But it's been a yeoman's effort to make sure all the good things you get from regular Linux are available in Android. It does take a little time to get used to, at least if you're playing with native libraries, and it is a good showcase for the CDT to show how flexible it is supporting new platforms.

Smartbook, finally a big enough screen

Enough blogging doom and gloom. There's a lot of exciting things happening in the mobile space these days. Today, I heard that Qualcomm, the chip vendor behind the current set of HTC Android phones, is showing off a new version of ASUS's Eee PC using their Snapdragon chipset. The chip is a 1Ghz ARM based SOC that supports 3D graphics and 720p video decode. It has a 10" touchscreen that likely shows the full 720p resolution. And it's small since the Qualcomm chip doesn't need a fan.

The most interesting part of this machine is the new category that Qualcomm is trying to create, the "smartbook". Not only is this machine a smaller netbook, it's also a bigger smartphone with all the 3G, CDMA, etc. goodness. And it runs most smartphone operating systems, including Android.

I need to play with the Android emulator set up to see how well it looks on a WXGA screen. But you can bet the web browser will be a more pleasant experience. But I wonder if the other apps have planned on being that large.

Anyway, this is exactly the device category I've been waiting for. The smartbook video over at Qualcomm shows some of the exciting possibilities that this platform can support. It's the ultimate in connectivity and user experience, and I'm sure other vendors are going to catch on.

Open Source 'leeches'

Ian pointed out this article via Twitter (I starting to get used to Twitter now that I have a client embedded in my iGoogle page). It a discussion by the author about whether community members who take but don't contribute back is good or bad for the health of the community. I think the argument is presented well on both sides, including quotes from our friends Michael Scharf (on the bad side) and Mike Milinkovich (on the good side). I think in the past I've gone on record as saying that it's disappointing when vendors don't contribute back, but that I understand the reasons why. And the author did point out those reasons.

But I think this is an important thing to consider at this stage of Eclipse's life cycle. Eclipse is a mature open source project. Vendors who were there in the early days have had long enough to figure out whether their investment in open source reaped the return they were hoping. And in these economic times, you'll see these vendors faced with the decision on what to do with that investment. Good, you do more; bad, you reduce.

And I think the results are a mixed bag. Clearly for the CDT, the growth of the community was phenomenal. I see a lot of recognition that the CDT is now the defacto standard C/C++ IDE, especially in the embedded space. Most vendors there have dropped competing products and jumped on the bandwagon. Customers are well aware of the CDT and that plays into their purchasing decisions.

But there's one factor of the "leeching" that somewhat scares me. What ends up happening is that it appears that you are investing in making your competitors' products better, while they are not reciprocating. That doesn't make much business sense. But that is a factor that's starting to get added to the equation. ROI is one thing, but supporting the competition while getting less in return is a nasty consequence.

The conclusion of the article really drove home that point for me. "..., the culture of collaboration, which is really the ideal of open source, doesn't run very deep in most companies. Institutions, as Woods pointed out, simply aren't wired that way -- yet." I think more effort needs to be put into changing the wiring...

Catch the Wave

It's a cold and rainy day today. We just had the freakiest hale storm I've seen in quite a while. It's a good day to be inside. While watching the Jays get pounded by the Red Sox (man, they Jays need better pitching), I watched the Google Wave keynote from last week's Google IO. BTW, I finally found a good use for twitter as I followed a couple of guys I know who were there who kept us up to date on what was going on. That was good because the video didn't show the standing O that the presentors got (it was good but standing O good?)

Anyway, I am quite impressed by the workflows and concepts behind Wave. If you haven't seen it yet, Wave is really just a good realization of collaboration tooling that we kind of see in IBM's Jazz, but more general. You could also see it as a redesign of e-mail systems to take into account and interface with or replace all the other social networking tools out there. The coolest feature is the real-time collaboration you can do, and of course, the API that allows you to play in this world too.

We've talked about IDE in the cloud a bit in Eclipse and, while not for everyone, I think it has potential. And Google Wave seems like a good framework to make this happen. Add an extension to interact with a server side Eclipse, and you get instant integration with the rest of your collaboration tools. Interesting potential.

But there was something else that struck me. Google is open sourcing pretty much all of this. They want to build Wave as an ecosystem to get as many people working through their browser as possible. I still haven't figure out how that makes Google money, but I'm sure there's a master plan at work there. But one thing you'll notice, is that Google worked for two years behind closed doors before pushing it out. This is the same way IBM put together Eclipse, how QNX pushed out CDT. It happens a lot.

And that got me thinking. Is this the only way innovation happens, i.e., in closed environments. How much innovation really happens in open source projects or at least how efficient is it? Realistically, it's a lot less than you'd think. Innovation happens when get get a crack team together in a highly collaborative environment where you don't need to spend time working with a community of diverse interests. So while open source helps make a technology popular, I don't think it's possible to create it there. But maybe that's stating the obvious.

Bjorn says "I had more to say but..."

And he turned off comments on his blog basically forcing me to put the comment here. The CDT committers know I refer to Bjorn and his use of Jedi mind tricks. And I'm falling into it again, making my thoughts visible on my own blog instead of hiding it in his comments page. You're Jedi mind tricks don't work on me, well, actually they do...

There are a lot of good things happening at Eclipse, and that you can't argue with. This week's demo of e4 self-hosting is definitely something very cool. Using the CDT in my hobby time this week doing something intense has helped me realize what a good thing we have and the great work that the contributors have put together. So as much nay saying and navel gazing we've done in recent weeks, things aren't all that bad.

But for those of us who have been around a while, the excitement at Eclipse is certainly well below the levels of those early days. I'll never forget those early EclipseCons and looking around at all the vendor positioning going on, trying to grab a piece of the spotlight. It was pretty wacky, and really fun for this lowly developer from Saskatchewan to be a part of.

But Eclipse has grown up. As Bjorn says, it is what it is. It ain't all that bad. Is it as good as we'd individually like it to be? No, it's not. That's the frustration you see. Especially as us old timers start to deal with that reality. But I'm proud to be associate with Eclipse and it has rewarded me well. And I think that's true for many.

So we keep plugging away. People will come and go, Bjorn included, and Eclipse lives on because it still meets that need that sparked the excitement in the early days. And we should all be proud of that.

Java is making me dumb

Sorry everyone who loves Java. But if you're a regular reader, you know about my love/hate relationship with Java. I hate it because I can't do the things I can do in C++ with it. But I love it because I'm making a pretty good living using it on Eclipse-based projects. So I deal.

Now, in my playing with Android and doing JNI development with it and OpenGL ES, I found myself immersed again in C++ for the first time in a very long time and loving it. One of the things you do with graphic programming is matrix multiplication. So I thought it would be cool if I created a Matrix class and an operator overload for the multiplication operator. So I could write code like this:

M4 myTransform = baseTransform * currTransform;

with all of these things as 4x4 matrices. Much less typing, no? :). So I coded it up and for the life of me I couldn't figure out why it wasn't working. Well, after mucking with it and trying different combinations I remembered something Bjorn Stoustrup mentioned in the C++ "bible". If you aren't doing anything special in your constructors, don't provide them. The compiler will take care of it for you and will do a better job of it than you could. So I removed them, and bingo, it worked!

Man I felt dumb, and at bit of a loss as to how I forgot how to do intense C++ programming. Clearly doing Java almost full time like I do, I'm out of practice. Now, you could argue that that's why people should stay away from C++, because it's too complicated. And, sure, it's not for the meek.

But I was trying to show the incredible benefits the gcc compiler gives you with performance over Java, especially in mobile where the JIT's aren't up to snuff (and Dalvik in particular doesn't even have one) and gcc can optimize using extended hardware capabilities like SIMD instructions. So there is a method to my madness and you put up with the pain to reap the rewards. Anyway, more on that after the Ottawa demo camp. Don't want to spoil the show :).

Tim Sweeney Interview, old story new

Gamasutra, a gaming news site, published an interview they did with the legendary Tim Sweeney of Epic Games, the Unreal and Gears of War gang. You can read it here:

http://www.gamasutra.com/view/feature/4035/from_the_past_to_the_future_tim_.php

I've read interviews from him before and have always appreciated the honest look he gives of the industry. I was even more impressed when he showed up on some of the "making of" material of my boys' Gears of War II game. He is quite the geek, but man he knows his stuff technically and he understands the business, which is a hard to find in a single person.

In this interview, the thing that really struck me was how he started Epic out of his parents house and dorm room in between jobs mowing lawns and his school work. Back in the 80's and early 90's the software industry really was driven by independent developers like this. The big guys at the time just weren't nimble enough to work with all the new technology coming along. It was an exiting time.

Zooming ahead 15-20 years, it seemed that this environment, the ability of independent developers to build software by themselves or in small teams and produce applications that sell enough to provide them with a decent living were long gone. But I'm starting to see that change. The are now a few stories of guys building iPhone apps in the same way Tim did back then and making it "rich". And as the number of mobile platforms grow and with app stores becoming an easy way for these independent developers to sell their wares, I'm sure there's a next generation Tim Sweeney coming alive out there.

Building Communities

There's been a couple of times now that presentations I've made have been recorded for posterity. I don't usually listen to them, mainly because I'm worried it really sucked and I felt embarrassed. But the main stage presentation I gave at EclipseCon was different on many levels. And having just finished listening to it, I'm glad it's been captured. It's available at Eclipse Live here:

http://live.eclipse.org/node/739

The title of the presentation is "The Rise and Fall and Rise of the CDT: Lessons on Building Communities". It is a very personal look at the history of the CDT and the lessons I learned about building communities through the roller-coaster ride I've been on for the last 7 years working on the CDT.

This little presentation is my proudest moment of my career. I put a lot on the line with it and you can tell at the beginning I was a bit nervous about that. But listening to it today, I am very happy with how it went.

If you are curious about my philosophies on working in open source communities, or just curious why I'm such a crazy man, here's an open window into my soul. And there is some humour to keep things from getting too serious.

Common Navigator misses the mark

What's wrong with this picture:



This is a Android project that includes both JDT and CDT natures to build an Android app with a native library using the upcoming Android Native Development Kit. As you can see both JDT and CDT contribute to the list of things in the project. The Resource system would put it's own twist on the project if I hadn't turned it off.

The Common Navigator was a great idea when it was proposed. Have a single navigator framework that projects could contribute to. I have the sense it wasn't meant to handle the use case where you'd want to see a project that that has multiple natures leading to multiple contributors. The result is confusing at best, and embarrassing at the least.

But it's a good example of where the Eclipse dream of interoperability is a bit of a failure. Yes, there is a bug on this (didn't have time to look up the number but one of the CDT committers warned that this was going to happen). And my understanding is that it won't make the cut for 3.5 meaning this behaviour will be seen in commercial products as well, unless the vendors fork and fix it locally. And it's just not the JDT's fault, CDT is helping here too, and not knowing, I wonder if it's something missing from the framework to help co-ordinate this.

It's pretty disappointing and, yes, embarrassing, as I try to get the Android community to use the CDT for this style of application. There's no reason to create separate projects for Java and C++. Everything else is working fine in the one project. They'll just have to make sure the expand the right version of the src folder to find their Java source, at least there's icons that differentiate it, unlike the assets and res folders.

Mobile, the new TRS-80

I'm embarrassed to tell this story, but it gives a sense of where I come from. I was in high school in the early 80's. This is when the personal computer world had mystique. You had the Commodore PET's, VIC 20's, and 64's. You had Radio Shack's TRS-80. Before I made enough money to buy my own Coleco Adam, I used to head down to the local Radio Shack in Regina, not far from Wascana Lake, BTW, and the sales guys there would let me type away at the TRS-80 they had there. This was where my passion for computer programming got it's first taste of fuel. It was great.

The Coleco Adam which ran Apple Basic was where I got my first full time experience and wrote my first program, a simulation of the old Stock Ticker board game. For university, I convinced my parents to lend me money for a Commodore Amiga 500. That was amazing. It was also my first experience with the mantra, the best technology doesn't always win and the IBM PC blew Amiga and Apple II and the TRS-80 et al away. It wasn't until I had kids that I finally broked down and bought my first PC.

Anyway, I'm telling this story because I see that same mystique in the new mobile platforms that we have today. You have that same diversity in operating systems and user interfaces and hardware shapes and sizes. You have the fight in processors, this time ARM versus Intel Atom, that we had back then with Intel's 8086 versus the 6502 and Motorola 6800. Who's going to win? I hope they all tie.

It's an exciting time. Programmers have a whole new set of platforms to build applications for. We've been getting pretty bored building the same old apps for desktops. And now we finally have good development tools that we can use to target any of these platforms (and yes, we need to get Eclipse working for iPhone app developers). For the Ottawa Demo Camp, I plan on showing what I'm doing with Android using their Java environment along with the CDT for native libraries. The productivity I'm getting is exactly what we hoped.

I'm having a blast. Programming for Android reminds me a lot of those days I spent down at the Radio Shack with that TRS-80. This time, though I'll probably hedge my bets and take a look at the other platforms out there as well, like iPhone, Blackberry, Nokia's Qt on Symbian, and even at Moblin, which I plan on getting up and running on my Via Artigo box.

Can you tell? I'm glad that mystique is back...

Wascana is over

Yes, I'm giving up on the dream. For most of my time working on the CDT, I've tried to help make it the C/C++ IDE for anything and everything. A lot of people flocked to it naturally mainly in areas where it had no real competition, especially in the embedded space. And lately I'm seeing a lot of uptake in the Linux desktop space as well. And looking at the vendors contributing to the CDT, it matches what they were investing in. And that's great. We've really met, and at times exceeded, the objectives we set out for ourselves.

But I always yearned for one more. The Windows desktop space. It was Microsoft Visual Studio 6 that got me into using IDEs and built my passion to work on one. And the CDT has always had Visual Studio as one of the bars we were working towards reaching. And as Microsoft reduced their investment on Visual C++, we were able to meet that bar and scream past it. I remember reading an article where they were struggling with indexing, an area where the CDT is now really strong. That was a proud moment for me.

Yet to really show we've met the bar, I felt we needed to have a real IDE distribution that had equivalent functionality to Visual Studio. That meant including a compiler and a strong SDK for building Windows applications. Wascana was my attempt at building that IDE. And I had a lot of great feedback on it. People loved the simplicity of a single install that gave them everything to do their work.

But a few things have happened since I started Wascana. Mainly, I switched jobs and am no longer working 100% on the CDT. In fact it is much less than that, probably just enough to fulfil my duties as project lead. So any work on Wascana would have to be on my own time.

And I need to be honest with myself and you, the passion I once had for CDT for Windows (which should have been the name of this project) is waning. As I blogged about last, my attention is turning to mobile. There are lot of really cool mobile platforms out or about to be released and there is a lot of opportunity in that space to make a difference. CDT for Windows, not so much. It's too much of a fight. A fight I don't have the time or the passion to fight any more.

I know a number of people will be disappointed by that. And to those who still want to see something like Wascana, I encourage you to carry the torch. I'm not going anywhere and would be happy to provide guidance. And who knows, maybe one of the vendors that I know sell a Wascana type thing will make their work more readily available.

Anyway, I'm very excited about what's happening in the mobile space. CDT has a huge roll there so my passion for that does not wane. In fact, there is one area that I think we really need to fix, i.e. CDT's build system, that can really help mobile app developers. And if I stop pushing for an internal builder and a fancy build model that I felt we needed to match Visual Studio and instead just provide a good Makefile editor and template engine, maybe we can dig out of that hole too.

It's Android Time

Well, I've had a lot of fun trying different things with embedded Linux and creating simple platforms. The idea was to help hobbyists and students start using CDT for building embedded applications. We have the remote download and launcher (using RSE) and gnu cross compiler support in the upcoming CDT 6.0 to help make it a real force in this area.

That work was pretty much all on hobby time. And it was fun to see it working. But I was describing that the hobby was just like work just on my own time. And my wife make a point that really hit home, "yeah, it's like work but you don't get paid". Uh, yeah.

That and there are already a lot of platforms out there for hobbyists to get starting using Eclipse for embedded development. And one of those platforms has a Market place that allows you to sell the little apps that you can make. Hobby, that pays. Hmmm.

Of course, the platform I'm talking about is Android. It has a great set of Eclipse tooling for writing apps. Yes, it's Java, and yes I bash Java regularly. But it gets the job done. And I think I have something to offer Android. Myself and a few others out on the webisphere have figured out how to build JNI libraries for Android. That gives you the best of both worlds. JDT for Java, CDT for the native libraries. You probably only need native libraries for compute intensive tasks that you can use the underlying hardware to help accelerate. But at times that is a need.

And building native libraries is pretty easy. Do a google search for Android Build System and you'll see a general description of it and the special Android.mk file you need to provide. You need to build your library in a subdirectory under the Android source tree. But once it's there you can create a CDT project that points to it. "make mymodule showcommands" and you're off to the races. And CDT's scanner discovery will even pick out the include path from the gcc/g++ commands.

Now I'm not sure how the native libraries work on real devices. It may be prohibited due to security concerns. So I'd like to try it on one before I push the idea too far. Rogers up here in Canada is finally getting Android phones in June, the same ones as T-mobile. I'll have to invest in one and see. But going through the SDK docs, I am getting the feeling this will be pretty rewarding, in more ways than one ;)

So what does this mean for my work on Wascana, which also competes for my hobby time? I'm still keen on it, and my new strategy of "stealing" the RPM contents from Fedora will allow that to take less time. But it comes back to what I was saying in my previous blog entry. It's a big burden trying to promote CDT for Windows development. Sometimes I feel alone and I wonder if anyone really cares. It's a burden I'm getting tired of carrying. Hopefully someone will step up and help, or some vendor will come in and fund some of it. We'll see.

Too few cooks

On Planet Eclipse we've had some harsh but healthy discussion on how Eclipse could be better organized for success. There are probably little things that need to be done, but at the end, I think the conclusion is that the Foundation staff are doing a pretty good job and Eclipse is organized to accomplish what it was intended to, to provide an open ecosystem for companies to work together on Eclipse platform technologies.

But I am still very worried about Eclipse. And the main problem I am seeing is that there are too few people making the wheels turn, especially as we push Galileo out the door. I figure if we removed probably 3 or 4 people from the equation, Galileo would stop dead in it's tracks and the release wouldn't happen. That is scary in my books. Even on the CDT, if I didn't do the countdown to releases, as I've done for the past 5 years or so, the CDT wouldn't release either. Or at the very least, someone else would have to jump in. And I won't even start with the e4 flexible resource project which currently has one part time guy actually doing code.

That's a pretty big burden for those few. And give the number of commercial vendors that rely on Eclipse technologies, I wonder if it's fair. The good news is that these few people have a lot of passion and are very focused on making Eclipse releases happen. So it will be a success. But understaffed projects is a chronic problem at Eclipse and that's where I fear it's future.

Maybe this fear comes from my own situation where I've been reduced to pretty much working on CDT in my hobby time plus a few hours here and there in my day job. But I know a lot of people in the same position and really wonder how we'll accomplish our goals in the upcoming year for Eclipse. That's the reality we need to figure out how to deal with and improve. Eclipse governance problems is incredibly minor compared to that.

MinGW Cross for Linux

I mentioned in my last entry that building stuff on my laptop leaves scorch marks on my legs (if you haven't read it, that won't make sense). This is especially true when building in my Windows VM. But I figure it wasn't so bad when building from within Fedora itself. And since I knew from my experience on the MinGW mailing lists that the developers there mainly use Linux as their build hosts, I figured that maybe a better path towards building what I need for Wascana would be do it that way to. Build a cross-compiler that ran on Linux and built Windows libraries.

Then I remembered that I ran into Andrew Overholt from Red Hat and he was excited to let me know that they were working hard on mingw packages for Fedora. That was before my Fedora days so I kinda blew it off, as "sounds good, I guess" (sorry Andrew!). So when I googled to find out how to build a cross compiler for MinGW, of course, I ran into the work at Fedora that he was talking about. And it blew me away. Not only are they packaging up the cross compiler, they're also packaging up a pretty thorough list of libraries to help you build Windows apps, many more than I was thinking of for Wascana.

So that's led me to wonder, since I'm now a Fedora fanboy :P, why not sync Wascana up to these packages. That way, whether your building your apps from Linux or from Windows using Wascana, you have the same library set available to you. I should also make sure the versions line up for the toolchain so that there are no ABI issues on the C++ side (which probably isn't a real problem anyway).

And interestingly enough, it brings into play the Cross GCC compiler integration that I build for the tutorial I gave at EclipseCon which I have just contributed to CDT 6.0. I should make sure you can use it easily in this environment too.

The team building the cross mingw stuff for Fedora have made all the decisions and I can extract what I need from their RPMs to install into Wascana. In fact a number of the packages already have zip files ready to grab with p2. Thank you Fedora team!

At home in my Fedora

Well, it's been about a month now and I'm starting to really feel at home with Fedora on my main machine, the Dell D830 laptop. The longer you go, the more packages you install that you find you need and eventually you end up with something pretty decent. My biggest issue was dealing with 32-bit apps and missing the 32-bit libs they need to run which you don't get when your in 64-bit mode (I have 4GB RAM and want to use it all). But that's pretty solvable if not time consuming. And then there's the never ending issue of docking and undocking the laptop, going from single screen to my second 24" LCD at work to my alternate second 22" at home. I still have to reboot to get the thing to recognize the second screens, and I even get the occasional hang when coming out of standby. But I'm dealing with that.

There are some things that just rock. I've been playing with the VIA Artigo I got at ESC a couple of years ago and building embedded images and toolchains and kernels and libraries is a dream with the tools available on Linux. There's no beating "-o loop" to peek at and create a file system image (just remember to type the right /dev name when doing a mkdosfs, doh!). Not to mention having all the utils and libs necessary to build cross compilers and such. And I've played with both buildroot and OpenEmbedded which are things you only want to do on Linux.

One thing I am learning though is that anything compute intensive probably shouldn't be done on a laptop. I think I'm melting my video chip as the external screen goes into fits as the disk and CPU get busy. Not to mention the scorch marks on my legs trying to watch the NHL playoffs and build a cross gcc at the same time. So I'm starting to use my Dell desktop at work more where I've learned the slickness of "ssh -Y". You can't do that on Windows.

But I still have a Windows XP image running in VirtualBox for those times I do need Windows. I still use Outlook for work. There's no beating it for the high volumes I get and the Calendar is top notch, and despite Evolution's attempt at Exchange integration, it's not quite ready for prime time. And of course, I need Windows to finish up Wascana 1.0 which almost ready for beta trials with Galileo. And I have a partition open to try it on Windows 7 (especially now that I mkdosfs'ed over my old Windows install, same doh!).

But I can't remember how many times I've gone between the Windows VM and Linux and forgot which one I was in. That is telling me that the Linux desktop isn't all that bad. I still hate the fonts (been complaining about that for years) and the multi-screen situation, but the rest is making it worth it. Highly recommended, at least if you're someone like me.

Navel Gazing

Man, we're sure doing a lot of navel gazing on Planet Eclipse about the future of Eclipse, thanks a lot to Bjorn's own navel gazing. I'm not sure why we are doing this since I am sure that Mike and the gang do that quite a lot themselves already and I'm not sure we're helping.

Anyway, I think it is a natural process to go through at this stage of Eclipse's life. Since the original consortium was created back in November 2001 (according to wikipedia, but I think that's pretty accurate), the software industry has changed a lot as you'd expect in 7+ years. Open source was pretty new back then and it was a bold move by IBM to start this thing. And, at the time, having an organization to promote and manage the growth Eclipse was critical to it's success. It made open source friendly to companies that feared it and it really pushed them into a new way of thinking.

Fast forward to today, there's no doubting that open source is now, not only accepted, but for many companies, it's the preferred way of working, especially on commodity platforms. Companies that used to play commercially in that space have moved on to higher ground or found niches to sell their wares, or disappeared all together, or are Microsoft. Open source is a commercial force, no matter what the Free Software people would like to think.

So what does this mean for Eclipse? I'm not sure. And that's why I am appreciating the navel gazing going on. What should it mean?

That made me wonder about Linux. Yes, it has a Foundation, but in the timeline of Linux, that's actually a fairly new development. Linux survived for years as a free software project. But if you look at the latest stats that I found (Apr 2008), you'll see that more that 3/4's of Linux development is done by developers that work for commercial vendors that have a vested interest in it. Surprisingly 9% of that development is by IBM.

I think it's pretty easy to imagine that if horrible things came to pass and the Foundation ceased to exist, Eclipse would live on. And for the same reasons Linux has. Too many companies have a vested interest in it to leave it for dead. And yes, the larger companies would want some sort of insurance against bad things, so you'll always need a Foundation, just like Linux has.

But how influential should that Foundation and the members that support it be in the day to day operation of Eclipse developers? Right now, it's a lot. The freedom of developers is very restricted relative to other open source projects. For some, it's even more restrictive than what their employers allow. And, sure, it's less restrictive than many commercially sponsored open source projects (OpenOffice comes to mind). But where are we on the open source project health scale? Or does that matter at all? Are things really all that bad right now?

No, no solution to the navel gazing here, and I guess more questions than answers. But it is a good time to think about it. Or maybe, I'm just doing my own navel gazing...

Writing Eclipse Plug-ins in C++

Well, not the entire plug-in. But I thought that would get your attention.

After spending a while mulling around with embedded Linux and Qt and qemu and thinking about OpenGL ES and how I'd build a handheld console or set top box that had a 3D graphical environment using something like Clutter, I'm now trying to figure out what kind of tools you'd need for such a world where 3D graphics was common place.

That led me back to something I tried a couple of years ago, trying to get OpenGL rendering in Eclipse. The idea was to provide a complete tool suite for building 3D games in Eclipse. We have C/C++ covered with the CDT. You might also want some 3D modeling tools for building characters and scenes. Why couldn't that be in the Eclipse environment as well. Yes, these are usually done by different people, but I'm thinking of the small, independent developer shops where that may not be true.

The OpenGL canvas widget in SWT makes this pretty easy. I installed the LWJGL library that allows you to make OpenGL calls in Java and I got the Snippet that draws a torus spinning around in an SWT window running. Very cool.

But as I often mentioned here, I "hate" Java (well, it's pretty much a love/hate relationship since I still pick it for my day job on Eclipse technologies). I want to have the option of using native CPU capabilities like SIMD instructions you get with the SSE family instructions. So I'd prefer to do as much as possible in C++.

So I did that. I got rid of the LWJGL code and replaced it with my own native library that implemented an init, resize, and draw routine. Essentially this is all the code needed to render into the canvas and you can do the rest with a few Java calls to set the current context and to swap the buffers. Very very cool. Now to get this running in an Eclipse editor and we're off to the races.

Here's a snapshot of what I have so far. And yeah, it looks like the LWJGL version, but, trust me, all the OpenGL code is in C++ behind the three native methods:

Planet Eclipse Ego?

I was trying to point a buddy of mine (who actually should know better, but anyway) to Planet Eclipse. He replied, it takes me here: http://en.wikipedia.org/wiki/Planet_Eclipse_Ego. I laughed long and hard.

So is it true? Is there a Planet Eclipse Ego? I'm probably guilty on that a bit. I find myself yearning to post to see my name up on the Planet, instead of just waiting to write something people would actually care about. But almost all the other posts are very informative and I don't see much evidence of any sort of "ego". Not much anyway ;).

BTW, Pat posted a comment on my last blog about being interested to pay a couple of bucks for the CDT if he could get it off an App Store. Maybe that's the answer on how to get more funding for Eclipse development. And it plays inadvertently into Bjorn's suggestion to stop doing builds at Eclipse. If you want Eclipse for free, check it out and build it yourself, just like with most other open source packages. If you want someone to do that for you, belly up to the App Store and get yours for cheap. Hmm...

App stores, the new economy?

You can't help but appreciate what Apple is doing with it's App Store which recently sold it's one billionth app the other day. That's a lot of apps, and that's a lot of money going from the consumer's pocketbook to the software developer and Apple. Apparently the Apple App Store now has around 35,000 apps listed. A lot of them are free and almost all of them are available for under $10. Certainly accessible to the masses.

Being a software developer, I can't help but envy the guys who are writing these apps. You hear the stories of guys who worked weekends in their basement to make good but simple apps that rake in revenue in the 6 digits in a matter of months. I don't think there are a lot of similar stories, but it does raise the eyebrows.

I'm also not clear how open Apple is with it's development environment. From what I've been told, you have to buy it from them. It's cheap, only $99 to get started. But their environment only runs on Macs of course and the feedback I've been hearing is that their Xcode IDE isn't anything to write home about. And there is interest in bringing Eclipse and the CDT into the picture.

So the question that comes to my mind is whether this success can be replicated by someone else. And, in particular, I'm looking at all these ARM SOCs with 3D graphics and multimedia decoding hardware running embedded Linux. It looks like this should be a no brainer.

Or is it? These platforms are easy to build but technology doesn't make an industry. My son has an iPod Touch and it's a pretty slick device that I'm sure cost Apple more than the $200 we paid for it, or at least they're breaking even on it. No, to build a successful platform, you need an ecosystem and that ranges from the SDK the developer uses, to easy access to their wares via an app store or such, to slick looking hardware consumers crave.

It's no easy task, and I see attempts by the open source source community with platforms such as Open Pandora doomed to failure. It's ugly, clunky, expensive, and lacking that ecosystem to make it successful. I appreciate their attempt. And I think it could work, if you got the big handheld vendors involved to build the hardware, and then used open platforms and tools, such as Linux and Eclipse, to build the apps, and then some one to build and maintain the app store to spread the wealth. But then maybe I'm dreaming or wouldn't someone have done this by now?

Update: I totally forgot about Android and it's app store. But then I'm so totally biased against Java right now, I find it hard to imagine you'll ever see the sleek apps that Apple has. I'm just weird that way. But I would be happy to be proven wrong.

Eclipse is a Drug and other Musings

I haven't written anything here in the last few days and was starting to get the urge to write something, anything. I feel compelled to say something about Bjorn's impending departure from the Eclipse Foundation. But I'm not sure I have much to say. As I mentioned in a previous post, he wears his emotions on his sleeve at times so I wasn't particularly surprised. But I too have a sense of change at Eclipse having been involved for almost seven years now.

Maybe it's because I'm very part time on the CDT in my current job and miss working daily in the open. But I look around the CDT project and see the same is true for many of us. And yeah, the CDT has a lot of functionality today already and we're pretty much in maintenance mode. But there are some cool things we've started talking about, like introducing static code analysis capabilities, and the build system is in much need of a redo. I think there's enough there to generate excitement, I just wish I had more time to promote that. But we'll see what I can do anyway.

And that's the theme of this post. For most of us working on Eclipse, it is very much like a drug. I'm hooked on it. We see a lot of people leaving companies only to find them pop up at another company that also works on Eclipse. We've even seen high profile Eclipse people leave the safety of their mothership to strike out on their own as Eclipse consultants to continue to help feed the Eclipse ecosystem. Once you've been there, you understand why. There are so many good people and so many high profile companies involved at Eclipse, it's certainly a high to be working at it.

So I don't worry about Bjorn leaving. I know he's hooked too and won't go far ;).

BTW, just ran across a blog entry describing how to use the CDT for Linux programming with OpenGL, something I've started to focus on in my hobby time. The instructions are a bit out dated, and I should do some real webinar tutorials on how to do things like this. But I'm fixated on the blog because it has a music player embedded into it and is playing some of my favorite metal bands :). Cool blog marketing trick. BTW, blogging is a drug too ;)

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.

On the future of Eclipse

Another great post by Bjorn on life at Eclipse in the new world and a great follow up by Michael Scharf on his thoughts on major changes needed to get there. These two posts made me think about what I'd like to see as a way to take Eclipse forward into the future.

Bjorn draws up a nice, clean looking "architecture" on how the cycle of value feeds the Eclipse ecosystem. Committer -> Project -> Product -> Profit -> Committer... Unfortunately there's a week point in this cycle which I fear will blow the whole thing up, and that's the assumption that vendors making profit on Eclipse-based products will be compelled to fund Committers working on open source projects feeding those products. I've seen too many vendors in this position not do that.

It's frustrating to see so many products based on the CDT and less than half of them contribute back to improve the CDT. Maybe the existing committers have done so good a job that they don't have to. Or maybe they're not big enough to devote developers to the cause in a significant fashion to justify the cost. What ever the case, we all know how hard it to bring in new contributors. You need to "Create the Need" for them to come. It certainly isn't out of good will, especially in these times.

Assuming the cycle fails all together, how do we ensure Eclipse projects remain healthy with new contributions? Michael brings up a solution that I've wanted to see for a while. He brings it up from an architectural perspective, which is what he does :), but I bring it up from a political perspective. The members should fund a team of core developers to ensure critical Eclipse projects continue to grow. These developers would be vendor neutral other than to follow the wishes of the members. The Foundation can help co-ordinate this but it's really on the Eclipse membership to make it happen.

The best example of this I know is with the Linux Foundation where they state that one of their goals is "Protecting and Supporting Linux Development". Now Linus doesn't work for the Foundation, but the members do fund his work there to ensure he can continue to work full-time and independently on the kernel. I'm not sure how well this is working in practice, especially with people other than Linus. But it's worthy of a look.

Interestingly enough, a lot of the members of the Linux Foundation are also members of the Eclipse Foundation. But, would such a policy work at Eclipse?

The Rise of the User Community

I'm a big Bjorn fan. I've gotten to know him pretty well in my years of involvement with Eclipse. There is no mistaking his passion for open source communities and he's like me, he wears his emotions on his sleeve when things aren't going as well as they could. I'm really enjoying his series on the State of Eclipse. Most of his points I totally agree with based on my experience with CDT, e.g., the need for Diversity and the continuing battle between the User and Vendor communities over the need of an Eclipse product that users can count on, where as I stated in the comments, this is an area that is fundamentally broken at Eclipse.

However, I can't agree that his solution of relying on the members to provide free distributions of Eclipse to replace the distros available at eclipse.org, is the right solution. I'll go further and say it won't even work. As I also stated in the comments, the members that produce commercial IDEs do so in competition with the free distros from Eclipse.org. Making a free distro available from their web sites and supported by them makes no business sense, and knowing sales people as I do, they'll veto it immediately to protect their revenue. Some companies may differ and that's the only hope I see for it.

And there's another reason why the distros at eclipse.org are important. There is a growing list of large User companies that are beginning to contribute to Eclipse to support the free distribution with their user base. You'll notice that the CDT has committers from Google and Ericsson, both of which are examples of this. Without their contributions, the CDT would certainly be worse off. I also met with another such large vendor at EclipseCon who also promised as their developers get up to speed they'll be contributing.

For the CDT, this is the most promising area of growth in the contributor community, and these guys rely on the distros from Eclipse.org. I'm not about to shoot myself in the foot and even if the Foundation put a stop to this (which Mike assures us won't happen), I'd still make a C/C++ IDE available from the CDT store.

It's been a great debate and that's what's so great about open source communities. Everyone has the freedom to state their opinion, Bjorn included. Take advantage of that and think about what they are saying. You might find yourself changing your mind. But don't do it in this case ;).

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.

Twitter is the future

I guess twitter is the next great thing in communication:

http://www.guardian.co.uk/media/2009/apr/01/guardian-twitter-media-technology