No where's that open source hat?

One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.

This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.

But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.

All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.

But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.

It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.

But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.

As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.

Remember PluginFest?

It's been a while since it was held. The Eclipse PluginFest was a really cool event organized by Ian Skerrett and hosted by the folks at Symbian in London. It was part marketing event and part engineering event intended to show how off the promise of Eclipse as a platform by doing some interoperability testing between the different products, focusing at the time on the embedded/mobile market. For the most part, it was a success, especially for tools up the stack like analysis and modeling tools.

But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.

But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.

The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).

I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?

Phone Games To Hurt Console Market?

Just read the NY Times article here that claims Apple is casting a shadow over the console game market. Of the 758 games shown at this week's Tokyo Game Show, 168 were cell phone games. That's a big number. I'm not sure if the premise is true, but it does open your eyes to a change that is underfoot.

And I think that's were my excitement over the mobile software space is coming from. These cell phones, like my personal HTC Dream Android phone, are decent little gaming machines. Now you aren't going to play first person shooters like I was earlier today with Halo 3 ODST, but for casual gamers they're a hit. And we see it today with the iPhone. When someone shows me their iPhone, it's usually to show off a game running on it.

Android has some growing to do to be a good software platform for mobile games. Good games need to get all the horsepower they can out of the phone without draining the battery, i.e. you need to write as much code to run natively as you can. Until Android gets support for OpenGL and other platform libraries needed to make games into their NDK, gaming on Android will be on a slow growth curve. But once it's there, watch out.

The new platform that caught my eye this week was Moblin, and not just because Intel owns Wind River (my employer). There was a big teaser announcement on Moblin, which until now was a netbook OS, being ported to run on Atom-based phones of the future. Taking a deeper look, I was pleased to see that Moblin really is a Linux "standard" distro with all the gaming libs you need, like OpenGL, gstreamer for audio, SDL for IO, that you get on a desktop Linux distro. I can't wait to see Atom in a phone and see how it compares to the iPhone and Android platforms of the day.

As I keep mentioning here in this blog, it's a great time to be a programmer if you get into the mobile space. There's so much innovation there, and so much opportunity to create something new. And being a non-traditional environment, it's a great place for Eclipse based tools to become the defacto standard, especially the CDT with it's flexible toolchain support and all around IDE goodness. There is activity going on in the community to bring that goodness to these platforms and I can't wait to try them out.

CDT 6.1, We're not done yet!

We had a couple of really good planning sessions so far this September as we put our plans together for the next release of the CDT, CDT 6.1 for Helios. We've been focused on Build and Debug. We'll continue to move the sticks forward for the editor and parser based features, but build and debug still have some major work to do.

On the build side, we're focused on improving the CDT Scanner Discovery mechanism that scans build output to try and figure out the include paths and defines that you are using for your build. That information is fed to CDT's parser to replicate the parse your compiler does. And that gives us pretty good accuracy to enable things like open declaration and content assist. This work will be a big challenge as we have a bit of a rag-tag group of part timers to try and get this problem area for CDT integrators and users fixed up. But it's a great challenge for me as a project lead to see if we can get as much done as we can.

On the debug side, there's some exciting news. As Ken Ryall from Nokia has been blogging lately, they've been working on a new debugger that's much more tightly integrated with the CDT, and they're ready to contribute it. Essentially, it's a replacement for gdb. Now you can argue whether that's a good thing or a bad thing, but I think it's a good opportunity to improve CDT's debug ability. And of course, it'll be able to sit along side our gdb support which continues to be important for a number of vendors.

But part of Nokia's work that has me most excited, is the native Windows debug support. This is an important step towards finally getting a complete Visual C++ integration for the CDT. I have a build integration almost ready to go. All that was left was debug support. While it is still missing support for Visual C++, Nokia's Windows debug API support gets us maybe half of the way there.

The other good thing about Nokia's work is support for gdbserver as the small agent that does the bit twiddling. Those who've done embedded development know about gdbserver as that's how you do remote debugging of targets using gdb. Reusing gdbserver gives Nokia's work a huge leg up for embedded developers working on all platforms that support gdbserver.

So despite being 7 years into our program, there is still work to be done on CDT. The community is still vibrant. We don't have the big vendor contributions like we used to, other than Nokia of course, but there is still a lot of work to be done and individuals and smaller vendors who are interested in helping. So to quote Monty Python, we're not dead yet :).

Eclipse Tools for Mobile Needs Some Buzz

I attended my first Sequoyah (Eclipse tools for mobile, except J2ME, but that's another story) meeting today. Why am I? Well I'm getting more and more into mobile app development in my hobby time, at least for Android anyway, and I'm turning that into a personal focus on better support in CDT for mobile application development. We can then make this available for platform vendors who want to better support developers making applications for their platforms.

My plan is to start by building a set of plug-ins that automate at least the build setup for Android JNI development. Debug is another story and maybe someone else can help with that. And we can look at what's needed for other open source mobile platforms down the road as well. And maybe some other vendor will come along and help out.

But, as I dig into what's happening with mobile at Eclipse, I'm a bit surprised, and disappointed, about how little there actually is. Motorola is putting forth a great effort and contributed a significant amount. As with most vendors (almost all) that contribute to Eclipse it is mainly focused on their own commercial needs. But they also don't seem to be getting much help from anyone else. It takes multiple companies to make a platform and it's sad to see that isn't really happening, despite all the marketing buzz surrounding Pulsar.

And I was also saddened to see Craig Setera's blog for help for the Mobile Tools for Java project. MTJ is probably the project hardest hit from vendors coming and going that I've seen. And after the push to get Craig's EclipseME project merged in for the reboot, I was hoping for greater things there.

On the Sequoyah call, I was asked for advice on how we could solve these things. Man, it's tough. You really need a community, and in particular, a vendor community, that has a vested interest in contributing. We had it easy with the CDT. Everyone needed an extensible C/C++ IDE and it made business sense to invest a person or two to help make it happen. I had it pretty easy as a project lead, and I feel for Craig and the Motorola gang as they try to get this thing going.

The only thing I can come up with is a trick I used in the "dark" days of the CDT after my team at IBM were reallocated. "Create the need". Find something that vendors will see the need to invest in. Usually, this is in the form of some platform piece that they know they need and that multiple vendors can work on, and then show that not enough people are working on it so it's going to suck in their product too.

I'm not sure that's going to work here since there seems to be a huge hesitation to make contributions from the vendors who could be contributing. But that was true with the CDT in the early days too. It was the QNX+Rational show for quite a while until Intel and TI broke the ice.

At any rate, I'm posting this as an attempt to help Eric C out. I'd really like to see Sequoyah succeed and for us to have a nice set of platforms and examplary tools for mobile app development at Eclipse. But that won't happen without growing the community and we'd certainly be interested in your thoughts on how we can make that happen.

Apple leading the way in multi-core programming?

One of my pet study areas is programming paradigms, something I've done since my university days looking at SmallTalk (object-orientation) and Ada (safety critical). The next great next battle line is how to take advantage of multi-core machines to do parallel computing without blowing our poor programmer minds. Intel is doing a lot of work in this area and it's really interesting that Apple is doing the same. I'm not sure why, but good on them.

The two technologies that seem to have sprouted from them and are supported in Snow Leopard are OpenCL, the Khronos standard for mixed GPU/CPU computing, and Apple's Grand Central Dispatch, a task parallelism extension to C, C++, and Objective-C with something called Blocks. There is a recent report from Hardmac.com that shows some real significant improvement form these technologies.

I don't know much about either, but this is definitely something I'm adding to my reading list for those nights I can't get to sleep (which if you're following me on twitter you'll notice are happen regularly).

State of the Doug

I've been tweeting a lot, but tweets tend to be temporal things that disappear after a short time, so I figured I should blog some of those things. Assuming anyone really cares, but that's part of the mystique and something I call the "cricket factor", when you tweet or blog, and no one's listening, and all you hear back are crickets in the night. But anyway, here's what I'm up to lately.

I made quite a splash recently stating my frank opinion on e4. I had lots of good feedback on that and I pissed off a few people. But I met my objective of making people think about it. To summarize, I worry about the stability of the platform and how e4 will impact the hugely understaffed projects up the stack. And I don't like RAP. If you're running web apps, follow the investment in JavaScript engines and put your UI code in the browser. Which also means I don't care much about the e4 UI work either. But as one e4 committer mentioned to me, "it's fun". I'm sure it is.

As cool and interesting my investigation into GWT has been, I barely get a day a week to do open source work and I still have a couple of things I want to do with the CDT, i.e., help clean up the build system, and support JNI debugging. And I want to spend my hobby time on other things. So enough of that. A lot of people get GWT and how it works well with Equinox, so it'll live on without me.

As for my hobby time, I am getting more and more pumped by what's happening in the Android space. So I'm turning back to that and hope to feed my curiosity on game development by making games for Android. Not sure I'll ever get far enough along to get something on the Android Market, but it'll make a good winter activity. And who knows, maybe we'll see Android running natively on Intel chips some day.

So that's where I am. I have way more ideas than time to work on them having a family and all. But I'll continue to blog and tweet things as they come to me, at least as they relate to open source, and maybe that will help others, or maybe it'll just feed the crickets.

Using CDT for Android Native

Android has a native development kit (NDK) which can be used to create JNI native code for Android applications. In this video, I show how I convert an Android project in Eclipse to add the C/C++ nature to it and set it up to build the shared library that gets included in your Android apk file. This gives you all the power of the CDT in combination with the JDT to build Android apps with native code. Except for debug, though, as JNI debug remains the lost holy grail for the CDT...

If you want to look at the code from the demo, you can clone or download from http://github.com/dschaefer/androidDemo.



Link to YouTube

Time to break down the Silos between the *DT's?

What started out as a personal need for writing and debugging JNI-based applications, both based on Eclipse and for Android, has turned into something bigger, a lot bigger. The hardest problem we face for what I'm doing is supporting multiple debugger technologies in the same debug session and ensuring a nice seamless experience. Showing both Java and C/C++ stacks merged together and stepping back and forth between them would be the cat's meow.

As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.

Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)

But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.

I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.

What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.

If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.

Using Git GUI with Eclipse

Here's my next set of screencasts showing how I use git and git gui in particular with my Eclipse projects. There are two parts. The first shows how to set up a workspace based on a git clone repository, i.e. copying a remote repository to your local machine and setting up an Eclipse workspace for that repository. The second part is how I commit and push my changes to the remote server as I develop code. Hope this is useful.

BTW, This is best viewed by clicking on the YouTube link and watching it full screen in HD mode.

Part 1 - Creating your Workspace

Link to YouTube

Part 2 - Committing and pushing a code change

Link to YouTube

The JNI Debug Problem

One thing I noticed the other day was that I'm doing a lot of JNI coding lately. In our Wind River Installer, based on p2 BTW, I have native code for doing a few things like compression and getting at the Windows registry. The CDT has native code for doing advanced process management, and getting at the Windows registry. I've played with Android native development which is all based on JNI. And I was thinking of hooking up the ALSA library to do Audio management with my prototype "Eclipse OS". That's a lot of Java/C coding. And, unfortunately, all without a debug solution :(.

JNI debugging was one of the early goals of the CDT. Unfortunately, it has never really materialized, at least not generically in a way we could incorporate into Eclipse. And given that I see a strong symbiotic relationship between Java and C/C++, I am getting more motivated to tackle this problem and see if we couldn't come up with a solution that we can integrate into the JDT and CDT (or maybe just the CDT).

But the first thing you run into when looking at the code, where do you start? I'd like to be able to step into native methods, hit breakpoints in native code and see up the stack all the way into the Java stack. And really have an integrated debug experience where you don't have to do much of a paradigm shift when going between the two worlds. And given the way the Debug platform is structured, that should be possible.

So there's different ways to slice the cat (not that I slice cats, I like cats). You could add an extension point to be able to plug in native handling into the JDT debugger. I'm not sure what the JDT gang feel of that, or whether they've hopefully thought of that. Another solution would be to build a new Eclipse Java debugger component, but base it on CDT's Debug Services Framework. That may make a more natural solution, but I fear it would be a lot of work and it would take a lot of investment to reach parity with JDT's debug solution.

I'd like to hear what the community thinks. What is the right solution. Hopefully we can come together, find the development resources, and finally reach this Holy Grail for the CDT.

What could an Eclipse OS be?

I got some really positive feedback on my quick little demo of the "Eclipse OS" prototype that I've started building. So I've started to capture ideas on the github wiki for the repository that I created there. Feel free to add your thoughts there, or here. Maybe if there's enough interest we could grow a little community around the idea. If not, that's fine too. I'm really just exploring a role Eclipse technologies could play in a browser based "OS" such as the announced Google Chrome OS.

Here's the link to the wiki and here is what I've started with: http://wiki.github.com/dschaefer/eclipseos

What should the Eclipse OS be? Take one of those new fancy 10" netbooks. Install enough Fedora to xinit the Google Chrome browser with the Flash plugin (necessary in my books for a full web experience) and launch an Equinox standalone server. What local web applications would you need to manage your netbook? Feel free to add to this list.

• Power Off. To shutdown the OS and power down, i.e. run the poweroff command. (Update: this is the first app and is now working).
• Install Manager. To install new web apps into the server using p2. Integrate p2 with yum to install native components that the web apps may need.
• Audio Manager. Similar to ALSA mixer but as a web app. To control the volume of the audio in the least. This could be a good first test of writing native code to help implement the service.
• File Manager. To look at and manipulate the files on the system, maybe even open them in the browser.
• Connectivity Manager. To manage wireless and wired network connections.
• Power Manager. To manage power saving modes.
• Office “Suite”. To prepare documentation and presentations while disconnected, like on long flights.
• E-mail. For those who would like offline access to e-mail.
• An IDE so I can build my web apps locally (thus the connection with my Web IDE (W-IDE) prototype).

Screencast Test

After asking around twitter, I had a number of people recommend TechSmith's Jing for doing screencasts. These are the same guys that do the masterful Camtasia which is a more full featured, i.e. expensive, solution. Jing does a good job at capturing my screen and audio. It's limited to 5 minute videos, but give that my main purpose is to share quick ideas with my blog readers, I think that's fine.

So here's my first screencast test. I'm showing the current state of my "Eclipse OS", i.e. Fedora minimal install + X + Chrome Browser + OpenJDK + a standalone Equinox app server. There's not much new here. But I'm really just learning how to use this media. One thing I learned as you'll hear half way through, is that my laptop fan kicks in. Drives me nuts, but anyway. Expect a lot more of these in the upcoming weeks. And hopefully, I'll improve the quality as I go to (like talking louder :).

Update: uploaded to Youtube which gives a much better viewing experience, especially in fullscreen mode.

Update 2: Planet Eclipse seems to filter out the embed object. Click on the title to come to blogger to see the real thing.

Eclipse OS?

I left a pretty cryptic entry last time. Essentially, I am trying see how easy it is to build a Chrome OS using Fedora as a base. It was pretty easy, and I have the instructions on how to do it. I'm going to put together a series of Jing screencasts (my new favorite screencasting tool), to show you how. That'll take a few days to get together, especially given the beautiful weather we're finally getting here in Ottawa.

But I wanted to show you a screenshot of the final result. Because, not only am I doing a Chrome OS look-a-like thing, I'm also putting Fedora's OpenJDK and an Equinox server application on it to run applications locally. In this case, it's the GWT Greetings app that you get when you create a new GWT project in Eclipse.

As I mentioned when I first heard of Chrome OS that it would be great if we could put Equinox on there to run local apps. Now I have a chance to expand on that idea and see whether it makes sense. Once I get the instructions together you can try it to. Could this be a start of an Eclipse OS?

Chrome OS Preview?

I'll be posting more on this later, especially how you can do it yourself. But I've built what could be the upcoming Chrome OS. I did it starting from the Fedora 11 net install and added what I needed, which wasn't much. Here's a teaser screenshot until I can firm up the recipe :)

Web apps make me think MVC

I'm blogging more than I'm coding lately, so I'll try to keep this brief. But I noticed someone mention MVC while I was googling around for practical information on GWT. After I thought about it a while, building a web app is a great example of the Model-View-Controller paradigm.

The model is data you store or derive on the server. You can use GWT's RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT's widgets and invokes the control using GWT's Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.

Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I've mentioned in previous posts, I don't think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You're better off using Android's native widget set in Java to accommodate the form factor. That's what mobile app building is all about. What I need now is an implementation of GWT's RPC mechanism in Java using Android's communication APIs, and really interesting things jump into mind.

What this leads you to is having three View implementations for my web-based IDE, that I'm now calling W-IDE. One in the web browser using full GWT, one in Android using Android's native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.

Now, yes, that's three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24" monitor, it's OK to have all those views and taskbars and such visible all at once. In a browser running in a 10" netbook, not so much, and you'd really like to make it page based to take advantage of the browser's history mechanism. And in a 4" smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.

At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP's server-centric architecture is OK to render in the browser (which if you can't tell yet, I'm not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we'll see. I think we have a lot of time to figure this out.

And, yeah, I guess I failed at keeping this short.

Are we de-evolving or on a natural evolution?

Talking around the office about a future with web-based IDEs, it was interesting that people are starting to get it, or at least, not scoff that it's something we'll ever to deal with. There are some good aspects to it for the tools business. At the least it's a great way to quickly get our products out to customers with minimal install fuss (the bane of my existence these days at work), and it's a great way to get immediate feedback on what they find valuable.

The question that needs to be answered is why now? I remember back in the 90's we were clamoring to get away from the client/server model. Everyone wanted a PC or workstation on their desk and former stars of the server world, DEC in particular comes to mind, faded away. Servers found a new life thanks to the web and it seems now, about 20 years later, we starting to climb back onto the client/server bandwagon. Why did we get away from that architecture and what's happening to make us want to go back.

From what I know, looking back, I think one of the biggest problems with servers in the 80's and early 90's was their sheer cost. They were expensive machines. You could buy 100 PCs for the cost of one of these things. Worse, yet, they didn't provide 100 times the compute power. The price/performance ratio made PCs a smart bet. They are both cheep and powerful. That, and they provided freedom to the user. If the server went down, they could keep working, and if they wanted to install some "forbidden" software, they could do it. It was really refreshing come to think of it.

But as any IT professional, or installer guy, would tell you, maintenance of all these machines is a nightmare, for the admin, and for the bottom line. As employees of larger companies well know, there are companies making money on software that beaver away in the background making sure all the other software is kept up-to-date and on the up-and-up. And, of course, some of the more rogue employees know how to uninstall that software and get it out of the way ;).

What the old server model provided was that ease of maintenance. You installed software on one machine and all your users had instant access to it. Of course there are risks to that as all of us tweeters had to deal with today, but with an improved focus on security and robustness with these critical server apps, like we had in the server era, those should become rare.

That, and looking at the cost of servers these days, the costs are way down. I would think that the price/performance curve is turning towards the server side. And just look around your workplace and count the number of CPUs sitting idly. It would be an interesting study to figure out what percentage of CPU power companies have is actually being used. It might make more sense to spend more on servers and less on desktops. You don't need that much power to run a web browser, especially with the ever improving JavaScript VMs that we are finding in them these days.

It's not really far fetched today to see a future, say five years away, where all of our apps are running on servers, in the "cloud" say, and we are accessing them through "dumb" terminals running web browsers, which is what Google's Chrome OS and I'm sure others will provide. The economics are right. The culture though is something else. Are users ready to give up the freedom that traditional desktops provide? I think so, but only if the applications provide significant new value. Tools that integrate with other web apps to allow collaboration over the web could provide that value. Running desktop-style apps that simply display themselves in a web browser, will not.

Time to come clean. I'm a Google fan-boy

I appreciate all the comments on my last blog or two about how e4 is doing a lot of the things I am trying with GWT. I don't dispute that. It's even interesting that RAP is planning to build on top of GWT. That's fine. I respect what the e4 guys are doing, it's a huge task and they are trying to modernize Eclipse as we all agree is necessary.

But I'm just wondering if using GWT directly while using OSGi web services to hook up to the IDE things I need in Eclipse, which is essentially IResource and up, is a better architecture to get us to a web-based IDE. And right now I'm trying to keep it simple and avoid any layers on top that e4 may be providing. Maybe there's a compromise choice. And I'll be open to that once I fail, which will not surprise me in the least. But I need to see first hand at what's possible in the GWT world. In the short term, that probably means I will appear to be anti-e4. But I'm used to being the bad cop by now, I guess.

So why am I doing this? OK. I admit it. While I have no contractual relationship with Google, I am a Google fan-boy. I have an Android phone which I am learning how to build apps for. The Android momentum will be unquestionable over the next few months as new handsets land like the rain in Ottawa this summer, including ones from our Eclipse friends at Motorola. Chrome is my default browser, although I'm using IE8 on my 64-bit Windows 7 laptop to check out its progress (which is actually impressive). I'll go back to Chrome once I get the RTM build installed. I use Google Mail for my Eclipse mails and am finding it nicer to use than the Outlook I use in my day job and I can access it anytime, anywhere, especially on my Android phone.

Google Wave and Chrome OS are technologies I am very excited about, and I have no doubt they will have a dramatic impact on our industry. And it's Google Wave that I have an eye on for this IDE work. That is my end goal. I believe following Google's way of doing things is important in that journey. And while not all Google products use GWT, Wave does, and it was the excitement for GWT I heard in the Wave lead's keynote at Google I/O which has driven me here.

And maybe that makes me the Google fan boy at Eclipse, so be it. You wouldn't bet against Microsoft in the last decade or so. I don't think you should be betting against Google now. And while the relationship is good on the tools side, I want to help make sure Eclipse isn't on the outside looking in when it comes to these run-time technologies.

GWT + Server-side Eclipse = W-IDE

Someone once asked me why we break up things between ui plug-ins and core plug-ins. My theory was that we could eventually swap out the ui with something else. I didn't really believe that at the time, and I'm not sure how well architected our CDT plug-ins are to allow that, but it sounded good.

So as I begin my journey down the road of web-based IDE's it really struck me that this was the time to swap out the UI. My theory goes like this. Google are the experts at creating web applications (and you may disagree with that, but stick with me). They have a framework for building them called the Google Web Tooklit, GWT, which allows you to program your UI in Java which then gets compiled into JavaScript. And, they have a really cool RPC mechanism, again all in Java, that overlays Servlets. Hey, Equinox plus Jetty gives you Servlets. Why not swap out the Eclipse UI code with a GWT implementation that talks to our Core code using Servlets?

A big thanks goes out to Ian Bull who reminded me of the example project he created last year that shows how to use GWT with Equinox OSGi. I have extended that a little to call into the Eclipse workbench, right now calling Platform.getOS(). This is the start of my prototype web-based IDE using GWT as a front end to the Eclipse IDE Core parts. And I am pumped the deeper I get into it. Feel free to follow along as I check my prototype into http://github.com/dschaefer/w-ide. Feel free to fork that and join in the fun. (BWT, I need to show you the cool way I'm using git, stay tuned).

As Ian says, "GWT + OSGi is a great platform!" And I am starting to see why. It really is. So much so that it confirms my earlier conjecture that Equinox would be a great addition to Chrome OS and I hope Eclipse people are talking to Google people about that. Wouldn't it be cool to see Equinox serving up local server pages, presenting a p2 install web UI to download and install bundles into your favorite mobile device. Yes, it would be cool.

Oh, yeah, and here's my vision

Ian pointed out that I actually didn't state what my vision for Eclipse was. I noticed that after I posted, it was probably the wrong title for what I ended up writing. I'll try again, maybe sooner than later, I'll actually get my point across.

I do have a vision for Eclipse, or rather, Eclipse as an IDE. Eclipse is so much more these days, I really need to differentiate myself. I am an IDE guy. Eclipse started as an IDE, turned into a great IDE, let's keep it that way. Maybe that's my vision. Keep a good thing going with focus on stability and quality.

I also have a vision on where IDEs are going, and I mentioned that in a previous blog where I stated the prediction that the desire for software developers to write software using mobile devices will drive that vision. But in the end, I think it's more than that.

This vision comes from watching the Google I/O keynote on Google Wave. If you haven't seen it yet, do so. Whether Google Wave is the right technology or not, the workflows they present are the future. I have no doubt of that. And it's all about collaboration, including real-time collaboration, through your web browser. And that let's it run on any platform with a web browser, which is pretty much everything.

I was especially struck with the demo of the team working and commenting on documents. Everything becomes a document, or a Wave in Google's terminology, and everyone can contribute to it. And it keeps track of who contribute what and when.

The first thing that popped into my mind, being the IDE guy, what if the document was a source file? Wouldn't it be cool to post a source file for review, have people attach comments to it, maybe even edit it to propose changes, maybe even work on it together live? Pair programming accross the internet? Doesn't that make sense in the global world we live in with software teams spread accross the world? Working in the same environment I do other collaboration. A bugzilla front end in Wave is a natural, integrated with my source in Wave, a truely integrated development environment?

Given that as a vision for IDEs of the not so far away future, how does Eclipse fit in. We have so much invested in making Eclipse a good IDE, I'd hope to keep as much as I can. And I think we can, removing the UI front end, which would be handled in Wave, and providing services that provide access to all the good information that our indexers and such provide. Even providing access to remote build and test machines to complete the edit, build, debug cycle. I think there's a significant role for Eclipse there, and thanks to Jetty and the HTTP Equinox/OSGi service, we could do that today.

So that's my vision, long and short. In the short term, though, I need to keep customers happy and try and convince new customers that Eclipse is right for them. And that's where stability and quality are criticial. And that's where I'm coming from. I'm Walt Mossberg, uh never mind :).

What is the Vision for Eclipse?

I'm on vacation, it's rainy, so I might as well write and maybe provide a little more insight into my thinking on e4.

Now, to start, I must first apologize for the tactless way of bringing this up as I did. As the title stated and I tried to reiterate throughout the entry, these are my fears for how the CDT fits in with e4. Nothing more, nothing less, and certainly not meant as a personal attack on anyone working on e4 (and no, despite common belief, I don't work on e4). It was really targeted at those outside the e4 community to take some time and understand how e4 impacts them.

I've sent a request for feedback to the cdt-dev list, so if you're there or even if you're not, please send me a response. I really want to know what the needs of the CDT community are so that I can properly feed them to the e4 team. The feedback I have so far, and so far it's been private, but that's OK, is that e4 is OK if we don't have to do anything significant to adopt it. Which then brings up the point of why adopt it if we're not going to take advantage of any of it. The other feedback that I got is that e4 isn't solving problems that our community has. Hopefully I'll get some more information. But, so far, it does justify asking the question and justify my fears.

My biggest fear for Eclipse is apathy. We're all working on our projects and being successful at it. As I said, I'm a happy user of the Eclipse SDK and CDT, especially with the new CDT 6.0. And I'm bragging about it to the Android NDK community as we speak. I know a lot of people question e4. I just happened to be dumb enough to blog it out loud.

My Biggest Fear for e4

A buddy of mine noticed that I don't get as many comments on my blog as I used to. He thought it was because I wasn't being controversial enough. He's probably right. Most of my readers follow this on Planet Eclipse and I haven't really commented on that much lately other than the great fun I'm having using it for my Wind River Installer work and for Android native development in my hobby time. I'm just a happy user now, I guess.

"Linus is a wise man"

Following Ian Skarrett on Twitter, he points us at an article in Linux magazine where they discuss Microsoft's Linux driver patch that I'm sure you all heard about. They quoted Linus, who is indeed a wise man with a cool head. He's just happy to get a contribution from a new member of the community and doesn't care who it is. That's certainly one of the big factors to the CDT's success as hard nose competitors worked together peacefully. It's the only way to be successful. Don't let emotions cloud your judgement.

Selfish need drives contributions

The other thing that Linus pointed out was that "I agree that it’s driven by selfish reasons, but that’s how all open source code gets written! We all scratch our own itches". He's bang on there. All of the vendors I work with on the CDT are contributing to it to make their products better. I'm sure that's true for many open source projects. For the most part that's a good thing, since open source users get the benefits of that work. But it also means, if there is a feature you need that none of the vendors do, you aren't going to get it. And as much as we beg people to contribute, it rarely happens. ~350,000 open source CDT users, ~3 contributors, that's pretty rare.

What does this mean for e4?

Well as much whining as the CDT community has done over the constraints we have to deal with via the IResource system, we only got one contributor to the e4 flexible resources project. And even there, the changes being done should end up in the 3.x series and isn't a major break from current system. So I can only assume that vendors are dealing with what they have and the need isn't really there for them. But I do know there are some big open source users who need it. Time will tell if they are big enough to invest in it.

But my biggest fear is the rest of e4. There are some pretty major changes in it. Will the contributor community feel the need to adopt it? And what do you do when certain vendors don't want to adopt it? What do we do with the CDT if none of the vendors step up to support e4? Stay on e3? What if Mylyn decides to support e4 and drop e3? What if we're forced to adopt e4 if the rug gets pulled out from under us on e3? And don't let backwards compatibility fool you, there is a massive verification activity in the least to make sure old plugins work on the new platform.

My big fear

I've stated this before, and it remains true today. We're headed into uncharted waters with e4. I fear that the contributing vendors to the CDT will not put the effort into supporting e4, because they don't have the need. And I think this is too big to artificially "create the need". Eclipse can't afford two platforms. Yet that's what we seem destined to have. A lot of CDT vendors consider the CDT finished. We have very few new features on the horizon. That will likely mean less contributions. How are we supposed to pull off adopting a new platform? That's my biggest fear.

Project Navigator: Apologies to all

I have to apologize to the Platform team and Francis in particular for my earlier complaint about duplicate entries showing up in the Project Navigator. It turns out that the problem was actually all CDT, or more specifically, how I set up the CDT part of my combo JDT/CDT/Android project.

By putting my source and build output into their own subfolders in the the project and setting the C/C++ Paths settings to point to them and not the root Project folder, the CDT stopped trying to display the other folders in the project in the navigator, the JDT folders in particular. No more duplication!

My disappointment has turned into happiness. I can now work on my Java and C++ files using the same perspective. The only thing that still doesn't make sense is the tool bar where the new Class button still depends on the perspective, but that's minor.

I'll have to come up with some way to automate the creation of what I call JNI projects that have the mix of Java and C/C++ so others don't run into the same thing I did. Maybe an improved Convert wizard.

At any rate apologies all around and thanks!

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...