Bye Bill. You will be missed

Reading the news I see that today was Bill Gates last day at Microsoft. Apparently, they held a tearful farewell in Redmond for him. And it really does mark a significant moment in the history of our industry and a time to reflect.

If I had a dime for every time I read someone say that Bill Gates crashed their machine or was someone personally affecting their life in some negative way, I'd be as rich as he is (well, maybe not). But as much as you may hate Microsoft and the methods they've used to drive their vision, you have to take a good look at what Bill Gates and company have done and how they've succeeded.

The biggest thing I learned from watching Microsoft is how important it is that you keep focus on software as a business. You may have the coolest widget or the cleanest framework or the fastest algorithm, but unless you have a business story and good business people around you to help sell it, it won't matter as much as it could.

And Bill Gates knew that. Surround yourself with good business people and you give yourself a chance. I've seen it too many times, great technology that has floundered because the team focused too much on the technology and forget to bring the marketing guys into the team, if they had marketing guys to begin with. And it's frustrating to see.

So on this day, even though I'm trying to build a C/C++ Development environment with the CDT that can beat Microsoft Visual Studio at it's own game, I pay tribute to Bill for all he's accomplished and all he's taught this industry. He doesn't hate you, he's just following his business plan.

CDT 5.0 for Ganymede, Come get Some

CDT 5.0 is out the door and available at your friendly Ganymede update site. I'm sure the Eclipse servers will be busy the next few days. The Eclipse community is vast and they love trying out the shiny new features that we've worked hard on all year to make.

I'm especially proud this year with CDT 5.0. With my new job at Wind River working on a p2 based installer, I've finally have a real reason to use it to write the JNI code that I need for some of the computation intensive parts of it. BTW, I now have proof that the Java version of an algorithm is much, much more compute intensive than a C version, check out the LZMA SDK from 7-Zip.

I'm really enjoying the experience. When I first imported the LZMA SDK into my C project, the first thing I needed to find out was where the main() function was. Let's try the Open Element dialog (Shift-Ctrl-T), typed in main, and there it was! A couple of Open Declarations (F3) later, and I was able to find the implementation of the decode function I needed to use. Awesome and I didn't even notice the Indexer running to find all this stuff. And everything else looked clean and worked well.

So yeah, the JDT guys are probably laughing since they've had all that stuff working well for a few years now. JDT has always been our bar (along with VisualStudio which I think we reached a while ago). But watch out. We may just make the CDT so good that people will wonder what the hype about Java was all about :)

:-O Nokia buys Symbian to EPL it

Wow. In case you missed it, Nokia bought up the rest of Symbian (it was already a major investor there) and have united with a number of Symbian stakeholders to form the Symbian Foundation to which Nokia will be contributing the Symbian OS. And from there, they will be working to provide an open source, EPL licensed, version of it.

Wow. We have CDT committers from both Nokia and Symbian and they are a great bunch. I still haven't figured out whether this is a good thing or not, but it certainly stirs up the pot as far as open source mobile platforms go. I think it also helps secure the future of the Symbian OS as a technology. It's hard to compete against the hype of Google Android and at the very least this will give Symbian some attention.

It'll also be interesting to see what kind of community evolves for it. They've certainly seeded it with companies that have a vested interest in Symbian's success. That'll give them a good start. As we all know in Eclipse-land, it's a lot of work to grow a community. But maybe growth isn't the prime objective here. We'll have to wait and see what the pundits say, but going open seems to be the most popular strategy these days to help ensure sure your platform matters. Mind you that may be the Google-envy speaking ;)

Back on Linux

I don't know why I get the urge to blog about my Linux journey. I'm sure it's not very interesting. But after a few days of working hard trying to set up ClearCase the way I want it so I can generate p2 repositories from our Wind River product release views, I've gotten back to why I was a *nix guy back in the day before Windows became a much better desktop.

I guess when you find a use for cpio, you are clearly destined to be a Linux junky. I've also fallen in love with NFS automounting (shh, don't tell my wife, she'll find that weird). When I can go 'cd /net/yow-dschaefe-linux' and get to my Linux box from anywhere on the WAN, that's pretty cool, not to mention handy. Doing a 'cpio > /net/yow-dschaefe-linux' from a ClearCase view on a Linux machine in California to my box in Ottawa and have fairly decent performance, that's the greatness of Linux file systems in a nutshell.

And using KVM to set up a virtual machine to run the version of ClearCase I need and from there to NFS mount a directory from my real hard drive and then to do a ClearCase view export back to my real machine so I can run the generator at full speed, it just rocks. It's not for the meek and it has taken me more time that I wanted to figure it all out, but Google is your friend and now that it's set up, I'm ready to go.

So, yes, I still think Windows is the better desktop, but for file and compute servers, Linux is clearly the champ. But of course, you all know that already :)

OSGi for native development?

I hinted at this topic in my last entry and when giving my crazy thought of the day last week. It's another Friday, but judging from the comments to those blogs and my gut, I'm convinced now that an OSGi implementation for native development isn't really that crazy.

Everyone has heard of the Microsoft Component Object Model (COM). Even if you don't chances are you've used it. It's now getting long in the tooth but it was a critical technology that led to the success of the Windows platform starting with Windows 95. It was a great way to build up frameworks with plug-ins and to write components that used the services of other components, e.g. a Visual Basic script that ran inside Excel.

But of course, COM is very specific to the Windows platform mainly because of it's reliance on the Windows registry which provided the directory to find the COM classes and objects you need. It also had some weird tricks with threading models and some wacky things called thunks to help to help performance when we were running Windows 95 on our old i486 machines.

But it's been done and there's lots of things we can learn from that, and from the limitations of some of the others, like CORBA. Using C++ as the core technology is one thing we would need to avoid. Different compilers have different ABIs, like how virtual function tables are laid out. As much as we try to evolve, at the end of the day, C is still the best language for interoperability and almost every language provides a way to call C functions.

There was some discussion in the OSGi community around something called Universal OSGi lead by Peter Kriens who is also involved in Eclipse. If anyone knows the status of that I'd be happy to take a look. It shouldn't be too difficult to start with the OSGi APIs that make sense and start implementing a framework to support it.

Are you situationally aware?

Part of my trip through geekdom lead me to Microsoft Flight Simulator. I've dreamed of becoming a pilot but never had the resources or eyes to do it for real. FS gave me a chance to play and get some sense of what flying is like, mind you without the inner ear working for you, it's certainly nowhere near the same.

Part of the thrill of FS for us geeks is the ability to add your own plug-ins to implement your own instrument gauges and your own airplanes. The gauge SDK was particularly interesting to me and lead me to ponder whether one could create a reasonable flight navigation system with maps and data, much like is common place with modern GPS systems. I think I had enough info to pull it off, but of course, never got the time to do it.

That investigation did help me cross paths with Garmin. They are the leaders in flight navigation systems for general aviation aircraft. They have some pretty sophisticated software and some pretty solid hardware to make it easy to navigate an aircraft through the airways. And they keep getting better, going from simple textual lcd screens, to two dimensional graphical displays showing maps in 2D. And the displays kept getting bigger and contained more and more information to help a pilot with his situation awareness, a key to survival in the cockpit.

And now, they've added 3D display of the terrain and obstacles and other aircraft in your vicinity. Here's a video of a reporter talking to a Garmin rep. It's like the world coming full circle. Instead of trying to figure out how to make a video game more real, they're trying to make reality more like a video game! The reporter asked the right question, aren't pilots going to be more interested in watching this wicked cool technology than look out the airplane like they're supposed to? I know I would.

Anyway, I hope this is the leading edge of what we'll soon see in embedded devices where it makes sense, i.e., more use of 3D graphics. I think it really helps the user experience be more real. We're seeing it already with Mac and Vista. And with announcements like Nvidia's Tegra and seeing what the Garmin has done with their system, I can see it useful for devices as well.

BTW, speaking of the FS SDK, when I mentioned OSGi for C++ the other day, that SDK came to mind and is a great example of how to build a simple component model with interfaces for providing services into a common framework. There are certainly other examples and makes me think standardizing on one at least similar to OSGi, might really be a good idea. More on that later...

Crazy thought of the day

It's Friday. It's been a pretty busy and long week. Got lots done. Working on lots of Eclipse related projects both internal and external. The Red Wings won the Stanley Cup (although I'm very proud of the Pittsburgh fans for their behavior after their team lost at home, they're real hockey fans). I bought a new car (a little Mazda 3 Sport, love it! but hate car shopping). So I think I'm allowed to think some crazy thoughts once in a while.

This one sprouts from a couple of different triggers. First, the latest Emacs discussion and how it would be nicer if we could integrate Eclipse better in a command-line environment. Second, comes from my interest in GUIs for embedded systems. Flash is one idea and trying to figure out how you'd hook a C/C++ app on a device to a Flash-based UI. Third comes from a bit of OSGi envy in that it would be a huge help to C/C++ developers if we had a component system like it.

So the crazy idea is this. Rewrite Eclipse in C++. Maybe rewrite isn't the right word since I hear there are people out there who actually like Java ;). But start producing C++ components that look a lot like Eclipse. I'd start with SWT which is a layer over top of some C and C++ code anyway. Shouldn't be that hard. You could then look at a C++ implementation of OSGi. Bundles would be easy to make, just use DLL/so's instead of jars (of course, I'm missing the point on other componentization issues that OSGi deals with but I can't be that far off). Then continue to add things as they make sense or people have a need.

I did a quick search, since I'm pretty sure the C++ SWT idea had been thought of before. I found a company, PureNative Software, that has actually done it. Mind you, they are using their proprietary Java to C++ compiler to do it, and I would think that leaves in a lot of the glue that SWT uses to bridge the Java/C++ world. But they do have a compelling story.

So I'm going to try and contact myself in a parallel universe to start working on it. Or maybe it'll just remain a dream. But I'll throw it out there to see whether you think it's such a crazy idea or not.

Eclipse versus Emacs, a battle unfinished

I was watching a presentation and someone was talking about integrating gdb with Emacs and showed a screenshot of it in action. I was at the back of the room and I had to squint, because when i first saw it, I swore it was Eclipse.

In this day in age of Eclipse having every feature of Emacs, save a good scripting and keystroke record/playback story, why would anyone still be using Emacs?

Well, of course, you'd be foolish to think that everyone using Emacs is just going to drop it and jump on the Eclipse bandwagon. And there are still some major technical hurdles that force you to be sympathetic with them.

And this is the challenge we face, especially in the technical and embedded space where the CDT is most popular. Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it's still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it's no good.

With all the talk about e4 and new architectures for the new world going on, we also really need to take a long look at how we can finally beat Emacs. Yes, I'm CDT Doug, but I still use XEmacs on Windows as my main text editor, even to look at C++ files outside of workspaces. I shouldn't have to, you'd think...

Can old NeWS be new again?

I'm going to really show my age here. Back when I was doing my Masters degree at the University of Saskatchewan (now there's a Canadian word that's hard to say even for Canadians), I was doing graphical representations of software models. Yes, my modeling roots go back 20 years. Essentially, I was trying to come up with a generalized diagramming model that could represent different modeling languages.

When it came time to do the prototype, I had a choice of windowing systems that ran on our Sun and HP boxes we had in the lab. Of course, we had X Windows, X11R2 if I remember correctly which was much better than X10.

We also had this new system from Sun called the Network extensible Window System. It was wacky but very cool and had a wacky and cool acronym, NeWS. Essentially you programmed the window server using PostScript (of all things) that was extended by Sun to handle windowing and input devices and asynchronous communication back to the client. It was quite bizarre to be writing PostScript code to do UI but it was a good way to separate UI from Core with an efficient protocol you got to create yourself to best suite the application.

Unfortunately, the implementation was very slow and awkward and the co-operative multi-tasking made it impossible to debug endless loops (but it did help me learn the Sun equivalent of Ctrl-Alt-Dlt). I eventually picked X Windows and this wacky new language called C++ and the rest is, well, even more history.

What NeWS reminds me of today is this whole concept of Web 2.0, and Flash/Flex in particular. And not because PostScript and ActionScript have the same suffix, but because the architecture is very familiar. And it made me wonder if we could use it in the same way, as a windowing system. I can't remember how I programmed the C side but if we used a similar API and protocol would it be any good? Now if I can only find some 20 year old documentation to find out.

NVIDIA enters the mobile space

I'm a fan of NVIDIA. I have their graphics cards in my computers at home and one of them has an NVIDIA chipset-based motherboard. I especially like their drivers both for Windows and Linux (yeah, I don't care if it's closed, it's still free). It all leads to a good user experience and a happy customer.

So when they make a big move, I pay attention. And today they announced their Tegra product line. News release is here. And a good analysis from Tom's Hardware is here.

Now, NVIDIA isn't creating anything new here. They're entering a market that's already dominated by some big players, including Texas Instruments (a CDT contributor), Freescale (another CDT contributor who's actually a committer), and others. And I'm sure these guys are saying "Big deal", been there, done that.

But the reason I find it interesting and potentially game changing is the reputation that NVIDIA brings with it as it joins in the fun. NVIDIA is known for cool products that entice excitement, especially with their video card business (just look at the flashy website they have). And I'm sure they'll bring that with them. Which, at the end of the day, will result in some really cool mobile internet devices, or MIDs as their marketing guys call them, which have some impressive video and gaming applications but with long battery life.

I'm pretty confident the other guys will spruce up their products to match, which in then end means a further invigoration of the mobile computing space. It's a fun time to be in the embedded software business.

A Pragmatic E4

So, yes, I was at the e4 summit last week. I've been meaning to blog about it but it's taking some time for me to realize what it was all about. And I think I am finally able to put it into words.

For those who don't know the history, e4 kinda tripped into existence as a side effect of the creation of an Eclipse incubator project to allow people working on it to check in prototypes and stuff. It was pretty innocent but it did scare a lot of people with the appearance that a new Eclipse platform was being developed without guidance from the community.

Of course, the dust has settled and fears subsided and IBM hosted the e4 summit last week to give people the opportunity to offer their guidance and, more importantly, to offer their help. It was a good, yet standard summit in my view. Lots of good ideas, but few actionable items, especially beyond what has already been actioned.

And to be honest, that's the way it probably should be. If anyone thinks that we can write a whole new platform and discard backwards compatability, they're kidding themselves. I think we'd all be fired if we came to our product teams with a plan like that. So I'm not worried in the least about that.

I think McQ has the right strategy and he tried hard to get the point across. You can rewrite the world with the best API and architecture and write a facade over top to let old plug-ins continue to work with as little change as possible. You can have your cake and eat it to. And, yes, it's a lot more work. But as I said, we'd be fired if we didn't do that. That's what will constrain the community from going hog wild on e4. And that's a good thing.

So if e4 isn't a great new platform, what is it? Lots of people are wondering that and I'm sure we all have different answers. To me, what e4 is, is the opening up of the platform to new contributors. It's a change in mindset of the platform team who have been maniacally focused on controlling change (justifiably so in my view) that they have scared off or rejected many a contribution. e4 gives them a chance to loosen up and be more accepting. And it is really up to the rest of us to take advantage and get in there and make the tactical improvements we need while this door is open. It would be our own fault to miss this great opportunity.

Pheonix has landed! A woo-hoo moment

Reaching new heights in geekness, I watched the landing of the Phoenix spacecraft on Mars last night live over the web via NASA TV. I don't know, I find there's lots of drama in space missions. It's an incredible task. One of the mission managers compared it to hitting a hole in one in Australia from a tee in Ottawa (ok, he said Washington but Ottawa is about the same distance :). Another manager closer to the action added, "with Australia moving". The good news is that they pinned it, relatively, missing only by 20km, rimming it around the hole before dropping it if you will.

The highlight for me was watching the jubilation as the guy called out that the spacecraft had reported a touchdown detected event. The gratification of years of work wrapped up in a single (probably) 2 byte event report is well deserved. That little report required so much technology to be working, it's mind boggling.

That feeling of jubilation is what I call a woo-hoo moment. Mind you nothing I've done compares to the moment these guys had, but I think it's an important aspect of all software development. It's these little moments that help you realize all that hard work you've put into the project actually works and you can do a little celebration (usually throwing my hands into the air for me and yelling "yes" :). It helps get the adrenalin going and really gives you the energy to start working towards the next one.

In my career I've had a number of these moments and I always try to schedule them into the projects I'm working on. And these moments I don't soon forget: the first run of an external code generated state machine from ObjecTime Developer happened a long time ago and I still remember when it happened. My work on the CDT has had a few too. The first outline view from CDT's first parser, the first content assist (which was a surprise since the Neifer just did a couple of tweaks to the binding resolution code and it just worked), and the first complete index of the Firefox source using the new Fast indexer that beat my set goal of 20 minutes (it's now around 13 minutes the last I looked). And more recently, I have the first install of Wind River product based on p2 (the DVD is hanging on my wall :).

I'm sure we all have moments like this throughout our lives. For software development, this is why I think iterative development is the only way to go. Not only does it give you a chance to show your customers progress and get their feedback, it lets you schedule in gratuitous woo-hoo moments.

Just call me a p2 fanboy

There's been a lot of bashing of p2 lately by blogs on Planet Eclipse. They seem to revolve around the lack of support for extension locations. I've never used extension locations, and I hate the fact that for whatever reason you would need to manage installs yourself by hacking around the file system.

p2, IMHO, is awesome. It manages installs as good as any install management system I've seen. It tracks versions, it manages dependencies with capabilities which is absolutely the right way to do it. It allows you to install things other than eclipse plug-ins thanks to the extensibility provides by touch points and repositories. When we're done you'll be able to everything your favorite install manager can do and more. From where I sit p2 will change the install industry.

So yeah, extension locations aren't supported any more. And I'm probably not the best person to speak on whether losing them matters. But someone needs to stand up for p2 because it is much needed. And I'm sure you can live without extension locations. I think the worse mistake was providing them to begin with.

CDT 5.0 looks good, now looking ahead

The CDT gang has put together a list of new features that are coming out with CDT 5.0 in a few weeks. Check it out here. There has been a lot of work further improving the indexer and we have a new refactoring framework with a few refactorings available. And there has been a little work on the build and debug side as well.

It was a good sign this release that we had no major architectural changes and got to focus on quality. There is a new scanner/preprocessor for the CDT's parsers but, trust me, that was much needed and Markus S did such a great job that we hardly noticed the change. Compared to the new indexer framework in 3.1 and the new build framework in 4.0 things went much more smoothly this time.

As I start to work on Wascana 1.0 based on this great work, I still notice a couple of areas that we need to work on for next year's 5.1. First of all is the tighter intergration of the Debug Services Framework (DSF) that is being built by the Device Debugging project. This is a pretty cool framework that is highly asynchronous and extendible. I am working on integrating MinGW's gdb with it as an exemplary integration both to help me learn DSF and to show others how to use it.

But to make this integration seamless, we really need to do something about the Launch Configurations. Right now DSF provides it's own set, meaning if you have CDT's current debug framework and DSF installed at the same time you get two sets. That's going to be terribly confusing. And, from what I hear, every vendor that integrates their own debuggers with the CDT add in their own sets. I'd like to see if we can get a common launch framework in place to help solve this, assuming there's support from the community for that.

The other big issue we've got to address is the CDT build system. We've tried to support two modes of build, using external build systems, and using Visual Studio-like internal build. External is easy. But, unfortunately, my feeling is that we've made things too complicated on the "managed" build side. There has been some great work done up until now by the committers, but we need to make sure we're meeting the needs of the community and either address them or provide the extensibility to allow them to do what they need but still provide a common user experience.

My real objective is to provide a common user experience for all CDT users whether they're using a commercial product or the standard open one. That means unifying the workflows for everyone. Maybe then it'll make financial sense for someone or a group of someones to write a CDT book to serve all of the CDT community.

It's all good, but not enough D's

Well, I think I'm finished my journey into Flash-land. It was an interesting experience. I'm glad I took a deeper look at it and gained an understanding about what the fuss was all about. The deeper look also left me wondering how free the Flash run-time components for devices will really be and how they'll actually deliver bits that will run on your favorite device without really opening the source, or at least making it public. But the technology is very interesting and I'd love to see animated UIs on devices become more common place.

But at the end of it, it left me wanting. The big new thing we're seeing on the desktop is 3D enabled UIs. 2D is good, but I think there are some really exciting things you can do when you add another D to the mix. You can see some of the potential in the UIs presented by console video games. I'll never forget my first eye opener with the old Rogue Squadron Star Wars game on our first video console, the Nintendo 64, and entering your name with the 3D spinning wheel of letters. It was fun and since you didn't have a keyboard it made the arduous task a little more pleasant.

What I think is missing, though, is a commonly available widget set that makes it easy to program 3D UIs. There may be some out there, but I'd like to see them become more mainstream. And as more and more devices come with 3D hardware accelerated graphic circuitry embedded in their processors and OpenGL ES 3D graphics API for devices becoming more ubiquitous, I'm hoping the industry can take a more serious look at this. Devices are becoming less resource constrained as we go, but they'll always be UI constrained. Maybe 3D can help.

Flash on the Brain

I hate it when that happens. A shiny object flies by and I can't sleep until I catch it. So I was up until 3 a.m. last night trying to figure out what Adobe Air/Flex/Flash/ActionScript was all about. It's actually pretty interesting stuff technically. But as a number of people commented when I brought it up a couple of days ago, you do get the sense of vendor lock in, at least for now. But the specs are all open now, so open source implementations of this stuff at least have a fighting chance.

So why do I care about Flash (other than my insatiable need to learn as much as I can about the software industry)? Well, it fits in with my interest in mobile devices, especially those based on embedded Linux. As these devices get more powerful and have bigger screens, the line between laptop and mobile device is going to blur. And I think the expectations of users on the UI for these devices is going to grow as well. Everyone oos and ahs over the iPhone UI. It's setting the bar.

But looking at a traditional embedded Linux box with a UI, does it make sense to run X Windows on it? X is horrible and antiquated. And it's very hard to build flashy (sorry about the pun) UIs with it. It certainly wasn't intended for resource constrained devices. Mind you the old X Terminals were pretty much embedded devices, but then where are they now...

So what are the alternatives? DirectFB looks very promising and is growing in popularity in the embedded world. It gives you an nice API over the graphics hardware and input devices that let you build your UI as low level as you need. But it does require you to build a UI from scratch.

So this is the architecture that piqued my interest: Adobe AIR (which include Flash and the WebKit browser) running on DirectFB. Which then opens up other interesting architectures. Like mobile devices turning into web appliances that let you work connected or disconnected (is there a Flash office suite app?). And with Flash's animation, video, and audio capabilities, you could build a pretty lively UI. And, from what I hear, there are a lot of graphic artists who have learned Flash who could give us a hand.

Now, I have no links to Adobe and this only crossed my mind as they "opened" up the technology with the Open Screen project. But if this move helps them build momentum in the mobile space, it opens up a lot of opportunities for mobile software developers, and graphic artists for that matter...

Happy Day in Linux-land

Thanks to everyone for their great comments on yesterday's entry on the frustrations I had getting ClearCase running on my new Linux machine. It gave me renewed hope that I could get this to work.

And I did. After reinstalling Fedora 8 as the host OS, I started getting a KVM virtual machine ready. I figured I'd try the new Virtual Machine Manager GUI to do it just like I do with VirtualBox. But when they say it's not ready for prime time, believe them. They're on the right track but to do anything serious, I think you still need to use the command line.

Another hurdle I ran into was running the 32-bit version of RHEL. I guess I should have looked harder at the KVM web page that said SMP was unstable in this configuration. It was. So jumping to the 64-bit version, I was good to go, 4 CPUs and a bridged network connection and all! I installed ClearCase and I'm in business. Now it's time to get some real work done. It was fun and I did learn a lot and gained an appreciation for virtualization, so it was well worth it.

Frustrating Day in Linux-land

So I'm busy working with my team at Wind on some new installer work and I need to set up ClearCase to get access to the bits that go into the install. I have this spanking new machine, Quad-core Intel, 4GB RAM, 750GB drive. I really got it so I can run multiple virtual machines on it for testing. But if I could run ClearCase on it too, then I could use it for install builds too.

But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.

So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.

As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.

So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.

MinGW gcc 4.3 lives!

This just in, Aaron LaFramboise has just released an alpha version of gcc 4.3 for MinGW. And, of course, they are looking for testers. I know I will be. You can give it a try to by downloading it off of mingw.org. I've been following the mingw-users mailing list and it's been a great place to discuss issues. It's not too busy but it's been busy enough to be useful.

gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.

Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.

Open Screen, Another Game Changer?

I just went through some blogs and the Adobe Open Screen web site to try and understand what's going on. If you haven't heard, Adobe is removing licensing restrictions on it's SWF and FLV/F4V file formats that serve us Flash content and all those crazy videos on YouTube and such. In the past, the license on the specs restricted the reader from creating competing players, which has resulted in some pretty weak open source players that relied on the developers reverse engineering and guessing at what the spec is.

Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.

So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.

Building Windows apps on Linux?

I had this interesting feature request on the Wascana forum. This user would like to use Wascana on Linux to build applications that run on both Linux and Windows. You know, that's an idea that could fly.

I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.

It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...

Help! I'm not connected...

I mentioned a couple of weeks ago that I have this idea for a visual programming language with inspiration from UML Action Semantics and the SynthMaker virtual instrument programming environment that came with my Fruity Loops thing.

So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.

Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.

Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...

C/C++ Top of the Heap, Sort of

The latest TIOBE Programming Community Index has been released. I don't put a lot of weight into surveys like this, especially if I don't know the methodology behind it. As far as I can tell it's based on the popularity of different programming languages as found on the web. I guess it's an all right measure and it co-incides somewhat with my personal observations.

At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.

C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.

C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.

One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.

One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.

Eclipse for Embedded in San Jose

I'm back in the valley and gave a talk on Eclipse for Embedded at the Embedded Systems Conference. Unfortunately it was at 8:30 in the morning today (Friday) when the exhibition, where all the fun happens, is all over. But I had around 40 people there which was good to see. I also did a shop talk session yesterday at 7:15 which had close to the same number. It was good to see that they made the effort to be there, and it was good to see that almost all of them use the CDT in their daily work.

I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.

The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.

I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.

I love the open source spirit

I came across the web site for the GCC and GNU toolchain developers summit. It's being held here in Ottawa and I am wondering if it might be a good idea to go and get more involved with this community. I do fit into the "enthusiast" category with my work on Wascana and my interest in MinGW. We'll see. I also don't want to take up space that someone more of an enthusiast would like to take.

At any rate, I came accross this in the FAQ for the event.

Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.

Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.

In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.

MinGW entering it's prime?

I have a monitor on files that get released by the MinGW project and I just got a notice that the alpha release of gcc 4.3 for MinGW has just arrived. This follows quite closely behind a tech preview of gdb 6.8 for MinGW which includes a number of improvements to gdb for native Windows development.

I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.

Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.

Unexpected surprise in my Fruity Loops

As I mentioned previously here, I am starting to get into making my own electronic music. I've played guitar for many years as a hobby (and I'm nowhere near as good as Steve Northover) but wanted something that I could play with on the road (yes, I was creating music on my flight down and back to EclipseCon). That and it gave me a way to mix hobby and work since I could build software synthesizers using the CDT and Wascana.

I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.

O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.

But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.

OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.

So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.

Eclipse p2, sweet!

As we hinted at EclipseCon last week, my team has been evaluating p2 as the framework for our new installer technology. We're essentially coming from an InstallShield world where we have these big monolithic setup.exe type things and we are looking to make our installs more flexible and open the door to electronic distribution. It's an exciting vision and we're pumped to be working to make it happen.

I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.

The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.

Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.

Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.

So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.

The community gets it

I just read Mike Milinkovich's post and it summarizes really well what Eclipse is all about. I'm going to use it as a reference whenever someone asks. And I'm going to add Cory Doctorow's quote to my list of mantras. "Ideas are cheap. Execution is hard". How true is that!

I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.

And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.

I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.

The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.

No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.

Another EclipseCon in the Books

Well, it's finally over. EclipseCon that is. But I think it also marks a beginning for me. I was able to meet so many people and accomplish so much this week, it was definitely the best EclipseCon for me.

I'm just going to drop a quick note here since I really need to get to sleep to catch the 7 a.m. flight out of SFO to Toronto on my way home to Ottawa. It's my wife's birthday and I need to get home in time for at least part of it.

So here are a few quick notes on my experiences here:
* e4 isn't so scary. What's scary is that I appear to have volunteered to drive the flexible resource model in the platform. It's a huge responsibility but it needs to get done and I look forward to keeping the momentum going to make sure we get the right solution in place for everyone who uses platform resources (which is quite a few people I hear!). And a big thank you to McQ and Szymon from the Platform Core team for helping us get this going.
* Embedded at EclipseCon is alive and well. I first ran into this at Eclipse Summit Europe where I met a lot of CDT adopters from the embedded space. I thought it was just a European phenomena. Apparently not. I met even more this week here. This is another thing we need to keep the momentum going.
* We need a grassroots embedded development IDE just like we have with Wascana. From the DSDP BOF there appears to be interest in this. And you can count me in with helping it out. And even more reason to figure out how to ship GPL code from eclipse.org since so much of the common embedded tool chain is GPL.
* Speaking of Wascana, the Microsoft announcement was very underwhelming. I need help interfacing the CDT to the Windows debug APIs. Microsoft, come help me!
* Not only did I learn about it, I learned how to spell Mylyn (sorry again Mik!)
* p2 is the future. Well, it's actually the present and it's great to see it coming together quickly. Given my new role at Wind River, expect to see Wind River participating and contributing.
* I'm getting old. I was in bed before midnight both Monday and Tuesday. Wednesday not so much, but I did feel good when I did. Having said that, I did consume a lot of beer this week, all in the name of community building :)

Well, I'll have more to say later.

Mylin & CDT destiny

It's an interesting phenomena at Eclipse how bug reports get to be famous. It's how issues are raised, where discussions on solutions take place, and patches get attached. There are famous bugs in Eclipse that I've heard about and finally, I think we've got one on the go for the CDT. It's bug 162558, the Mylin bridge to the CDT.

I've heard great things about Mylin for a long time. An old colleague of mine raved about it. I tried it and it has a great Eclipse interface to a number of different bug systems. But today, I learned from Mik's talk about the task management features that Mylin provides and how it cleans up the UI to help you focus on what you are working on. It's a different way of working, but I can see that once you adopt it, it'll give developers a huge boost in productivity especially when they are working on multiple things at a time.

We've had bug 162558 around for a long time which asks for CDT support in Mylin's task management system. I think there was concern that it would be a lot of work and CDT developers have always had other things to work on. But Mik promised on the report that it would only take 2-4 weeks. And now we have Jeff Johnston from Red Hat who has signed up to help and has a new plug-in ready to show.

I really think that this is a hugely important development for the CDT. In the C/C++ world, our biggest competitor is still emacs/vi and make, i.e., the command line. It's too easy for new CDT users to get frustrated and throw it away and go back. Much more so than Java developers, for example. Ever write java code with command line tools? It's a lot easier with C/C++ where the tools have been optimized to work well on the command line.

We really need to show the value that will pull users through the learning pains of adopting Eclipse (mind you we need to address those too) and tools such as Mylin can do that. You won't find a command line version of Mylin. So we'll work hard to get the CDT Mylin bridge into CDT 5.0 for Ganymede. It'll be a fun thing to add to my CDT demos and hopefully can convince more people to use the CDT.

EclipseCon is about people

I finally headed up to my hotel room to finish going through the CDT Build tutorial. I think I'm ready, wish me luck.

I was having way too much fun meeting people and catching up with the CDT crowd. That's what this event is all about for me. There's lots of talks I want to go to and learn some of the new areas of Eclipse that I haven't been involved in. But I may end up just sitting in the power lounge meeting people, discussing CDT and Eclipse issues, and just enjoying being a part of this great think called Eclipse.

At EclipseCon 2008

Well, I'm finally settled here at EclipseCon. I'm helping give the CDT Build tutorial latter today and haven't had much time to look at the matereal yet. So I'll be doing that the next few hours.

Of course, I made the "mistake" of coming up to the power lounge to find Chris Recoskie and ended up running into quite a few people. That's the great thing about EclipseCon, it's meeting the people you talk to on the mailing lists. It's a lot easier to talk in person and it's always good to put a face with a name.

The flight down was great and, as it seems to always be, you end up meeting other EclipseConers on the flight. I ran into Jeff McAffer in Ottawa then we picked up Eugene Kuleshov and Andrew Overholt in Toronto. We were a merry band of Eclipse committers and it made a usually arduous journey a lot more fun.

I'm really looking forward to the week. I come with two hats on now. Of course there's the CDT where along with the tutorial, I am giving a short talk on CDT 5.0 Ganymede state of the union, as well we have the CDT BOF on Wednesday night where we will get to meet all the CDT gang and learn a bit more about eachother and talk CDT.

My other hat takes me in the direction of the Eclipse p2 project and Eclipse installer technology in general. Jeff gave me a really interesting demo of p2 used in a way I never thought about, i.e. provisioning software on devices. And it doesn't have to be OSGi based as many assume. It gave me some ideas.

And of course, who could miss the e4 discussions as we as an Eclipse community start to plan out the future of the Eclipse platform.

So if you're here, and you see, please stop me and say hi. I'm always interested to hear your take on the past, present, and future of the CDT and Eclipse. And I really do learn a lot from hearing your story.

CPU vs GPU wars

I just finished reading this great interview on Tom's Hardware with Epic Game's CEO Tim Sweeney (of Unreal fame). This is actually the second part of a three part series and I really like his opinions on the state of PC gaming and what the future may hold.

The part that got me interested in writing about it was his conjecture that in the future, as was in the past, graphics rendering is going to be done in software instead of hardware. As GPU (Graphical Processing Units) become more powerful and general purpose, and with CPUs going multi-core, it just makes more sense to leverage that power in a flexible way with software renderers. He figures it'll get to the point that game programmers won't use DirectX or OpenGL, but will bypass it all and write code that runs directly on the hardware.

He then takes it a step further. If CPUs adopt wider vector computation, or GPUs adopt general purpose instructions, we could see the dividing line between the two blur until you can't tell. He predicts GPUs will reach a point where you can run a Linux kernel on them. If that happens, why would you need a CPU?

As it has been of late, the gaming industry is really driving the investment going into PCs architectures. I doubt any of this would be happening in the consumer space at least without it. But this could really change the players. Could nVidia build their own PC architecture without the help of Intel and AMD? Is this why AMD bought ATI? Is this why Intel is investing so much in multi-core architectures? I don't know, but I can't wait to see what unfolds.

How to tell a project is really open

So how do you tell whether a project is truly open or not? Well one way I use is to take a look at the developer mailing list for that project. The volume of traffic there is a good judge not only of the activity of the project but how well the developers communicate with the community.

Now it's much better to look at the archives. I remember signing up to the gcc developers list for a few minutes when 20 or so message jumped in and I quickly unsubscribed. gcc is a massively active project that has contributors that love to communicate. Good or bad, it is what it is, an open project.

And I guess there should be some metric you could calculate to measure the openness, something like number of mail messages versus lines of code committed. If that number is low, you have a closed project, if that number is high then it's open. Not sure if that makes the most sense but then, I wonder that about most metrics anyway.

At any rate, I decided to take a look at a number of *-dev mailing list archives at eclipse.org and see how many pages of items there were in the last year. If you get a chance go check out the archive for the cdt-dev mailing list. I'm proud to say there we're 26 pages of items in the last year. We score pretty high. Mind you being a diverse set of contributors, we have to communicate via the list. It's the only way to get the message out to everyone who needs it.

So when I talk about a project being truly open, I mean the daily business of that project is done in the open on a publicly accessible forum. And if you fill up the subscribers mailboxes with good information, even better.

What do you want Eclipse 4.0 to be?

Well, in a very awkward move, the Eclipse Platform project has combined with the Eclipse Rich Ajax Platform (RAP) project to create a new "component" of the Eclipse Platform called "e4". Apparently they have built a prototype of what the "next version of Eclipse" will look like. I'm a big fan of innovation, I just wish that the community was involved even earlier. And despite Chris zx's claim, you involve people by reaching out to them, not just calling meetings and hoping people come.

The timing of this is probably what drove me off the deep end (and I made some pretty snarky comments on the planning council mailing list and I do apologize for that). You see, I have just given up on my attempt to support flexible projects for our CDT users. As a refresher, I was attempting to implement something like the way Visual Studio manages project files by allowing users to add files and directories from anywhere and to exclude others from showing up in the resource tree.

We had a lot of discussion on the cdt-dev list and I think we've concluded that the only possible solution is to modify the Platform to treat this as a first class feature instead of the crazy workarounds we were trying to do. There are quite a few features in the CDT that started out as workarounds for the Platform's failings. It would make much more sense if we did them by fixing the Platform itself.

But then this "e4" thing came. I have no idea what it is technically. But from what I understand it's an Ajax based thing, since the RAP guys are heavily involved in it. When I think of my vision of the next version of the platform, Ajax isn't on my list. Visual Studio feature parity is. That's what a lot of CDT users care about, including paying ones.

I hope that this new "e4" component/project/people are open to everyone's vision of what Eclipse needs to be. At the very least this has opened up the can of worms and we can get this out in the open. Everyone who depends on the Eclipse Platform needs to participate. And that's probably everyone. I'm not sure how it'll work. But it is critical for Eclipse as a whole to ensure that it does work.

Understanding the Canadian Accent

I had a great experience on my first business trip when I worked at ObjecTime. I went with some of our customers from Lucent (this was over 10 years ago when Lucent was a new name) to take a course on the Chorus operating system. They were great people and really made me feel part of the team which is the best way to be if you're a supplier. (I wonder where they are now...)

At any rate, one of discussions we got into talking was about different peoples' accents. I mistakenly made the claim that Canadians didn't have an accent. I was quickly proven wrong and I've since had a number of people comment about my accent. What is this Canadian accent anyway and why do we talk funny like that?

What brought this to mind lately is the way Doug Gaff pronounces Wascana (sorry Doug ;). For those who don't know I got the name Wascana on the trip my family and I made back to my birthplace of Regina, Saskatchewan. Regina has a beautiful man-made lake on the provincial legislature grounds called Wascana. Having spent my high school years there, I figured I knew how to pronounce it. But it turns out it's a great showcase of the Canadian accent since a lot of people I know (not just Doug) have a hard time with it.

So the Canadian accent goes like this. We love to pronounce our vowels. Why put them there if your not going to say them? So the pronounciation goes like this: 'Wass' 'can' 'ah'. All the a's have the same pronounciation. It's not 'Wass' 'con' 'a' as I hear a lot of people say. So if you're wondering if someone is from Canada, ask them to pronounce it. Or pronounce 'about'. You know 'ow-t' with an 'ab' on the front.

It's one of the things I like most about my job and my involvement in Eclipse. I get to meet people from around the world and I get to hear the way a lot of people talk. And you learn that to communicate, you need to understand it. And I'll never forget the confused look on the taxi driver's face when I went to the Eclipse PluginFest in London last year and asked to go to 'south' 'wark'. I showed him my hotel reservation for Southwark Street and he said, "Oh, 'suthuk'". eh? (BTW, thanks to Andrew Ferguson from Symbian in London for teaching me the right way to say it :)

Conference season is upon us

I'm having a hard time getting into writing my paper for the upcoming Embedded Systems Conference. So I figured I'd spend some time writing here where I seem to never have writer's block, at least once I find a topic to talk about and a second to do it.

But it's a sign of the time of year. EclipseCon is just over two weeks away and then this year the Embedded Systems Conference and the Eclipse PluginFest for Mobile/Embedded are happening in the same week in April. Time to get prepared.

The PluginFest is a special event that we started last year. It was a pretty interesting time. Part of it was the thrill of spending some time in London, England (which I hear is nicer than London, Ontario, Canada but I've never been to the latter :). But I think it was mainly the chance to get together with Eclipse people again. We have a great community that have some really interesting and passionate individuals that make these events a must attend.

The PluginFest is a bit different than your average Eclipse event, in that you are encouraged to talk about your commercial product and work with other commercial vendors as we prove that the concept of plug-in truly does enable the interoperability between these products that we promise.

And a key component of the interoperability story is the Eclipse platform projects that everyone works to extend. These projects, which include the CDT and DSDP projects, become a bit of a focus as well. I talked to a number of people last year who had questions and ideas for me and the CDT. And I hear there's a keen interested in having project members present again this year.

But that left me a little concerned. EclipseCon is actually a month earlier than the PluginFest this year. And in many ways EclipseCon is meant to be the venue for people working on projects to gather and discuss and ask. For some reason, though, we've always had trouble getting a strong program and attendance from the embedded community for EclipseCon.

It really shows that there is still a lot of work to be done to boost that community. Which is odd, since they are a community that I think desperately needs Eclipse technology to work for them. But then maybe that's one reason why. It doesn't necessarily work for them.

Eclipse Board Election Under Way

It's been a quiet campaign, I guess, at least relative to other elections that are going on right now. Thanks to Ed Merks who we can always expect to stir up the pot :) We did end up have a really healthy debate over the way the Committer reps are elected. One thing we're not short of at Eclipse is passionate contributors and that's good for everyone concerned.

I encourage all the committers to take the time to vote. It's a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you're needs.

I have no idea how I'm going to fare since my campaign budget didn't allow for any polling ;), but I'm glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I'm not sure we'll get CNN to cover the results, but it'll be fun to see how it all unfolds.

A Voting Scheme That Promotes Diversity

I was going to leave a comment on Ed Merks blog entry on "One Committer, One Vote?", but I found I filled up the space. That probably means I should do it in my own blog.

For those who haven't read Ed's blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.

But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.

Now, it doesn't shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I'm not sure I have much more of a chance of winning than they do. And that's good for Eclipse all round.

Code like you won't be there tomorrow

One of the things that we deal with on most software projects that continue on for a few years is turnover. People come and go. I'm not sure it's more prevalent with the software industry than others, but it is painful. As managers we spend a lot of effort making sure transition plans are put in place when it happens so that the asset that is the developer's knowledge isn't lost.

Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.

But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.

The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.

The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.

So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.

Sun Buys My VirtualBox

One of the issues I have to deal with when building Eclipse-based software is the need to test on a number of different platforms. Yeah, "Write Once, Run Everywhere", whatever. To build a proper IDE and especially the new Installer stuff I'm working on, you need to access the native platform. There's no getting away from it. And with that, you need to deal with all the "special" behaviors that these platforms offer you.

And when you're dealing with many platforms, it's gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I've mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I'd try alternatives.

One I found that worked pretty good was VirtualBox built by German company innotek. It's got a weird license. It's "Free for personal use". It has an open source aspect to it but it's a subset of the whole thing that's free for personal use so it's pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.

So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 - innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!

I'm not sure how to interpret Sun's motives or what will happen to VirtualBox once it's in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.

MinGW gcc 4.3 - not quite dead yet?

As I march into the exciting world of Virtual Instruments and VST and using the CDT build something I think is really cool, I keep running into the question: what toolchain should I be using for Windows development. Without a debugger, what's the point of using the Visual C++ compiler. My gut tells me that it's probably got a better optimizer than the old 3.4 that MinGW has at the moment, and that will be key to building a high performance plug-in for digital audio workstations.

At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?

I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven't really seen much progress. But maybe I'm just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.

So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn't I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I'm going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.

In my mind that would be huge. With gcc 4.3 with it's strong optimizer along with other goodies like OpenMP, we'll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.

You're Running for What?

I guess if you look through the history of this blog, I've complained the odd time about how frustrating it can be to work in the Eclipse environment. Now don't get me wrong, the frustration is incredibly minor compared to they success I've had in helping create a successful C/C++ IDE in the CDT. We've been able to put together a solution that has been very well received by the community and is having good commercial success as well. It's all good, well at least for the most part.

But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I've decided to throw my hat into the ring. It's not an easy decision. I wonder how successful I'll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it'll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.

So what are the kind of things I'm talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I've seen a lot of frustration but I think the solutions are available and don't require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what's going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I'd be interested in finding ways to ensuring that these guidelines are respected.

Of course I have other things that I've mentioned in this blog before. I still am saddened that we can't have complete IDE solutions hosted and branded as Eclipse distributions. I'd love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn't the only solution here.

And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.

I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.

Yearning for a good Windows toolchain

I've really started to get into this software synthesizer thing with VST albeit the older 2.4 version since most digital audio workstations don't support the new one (they could learn a lesson from Eclipse about keeping a community happy with API stability). There is a pretty good community sharing ideas and tips and examples. And it's a pretty low overhead activity that has a better chance of turning into a hobby than some of my other grand schemes. Most free software synths seem to be build by individuals (versus my desire to explore game development - ever see the credits at the end of a game?).

So I've started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I've got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I'm using the CDT, of course, with the Microsoft Visual C++ build integration I'm working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.

At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I've had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That's fine for simple things, but I found myself missing a real debugger integration as I've started to get interested in the more complex data structures I need to deal with.

Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I'd love to see gcc 4.x for MinGW and I'd love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn't a bigger community working on better gnu tools for Windows development.

Nokia gets Qt

Sorry, I had to use this title. No one else seems to have picked up on it. But then maybe most people are like I was until I actually met a couple of developers from Trolltech at Eclipse Summit Europe in October and learned that it's actually pronounced 'Qute', Not Q.T.

At any rate, the big news in the mobile software industry today was Nokia's purchase of Trolltech. It's another piece of news that struck me as potentially game changing. Certainly Nokia has been under the gun with all the hype behind Google's Android platform. I think this is a strong move by Nokia to firm up their story.

Now, I've been a little luke warm to Qt. I've received a number of requests to include it in Wascana. I can't. And it violates one of the policies I have for Wascana. That is the open source version of their library uses the GPL license. That means only GPL applications can use that version of it and I don't want to get into that game. "Free" software is a paradox. You can't have freedom of users to do what they want with it, and freedom of developers to license their software how they see fit at the same time. And, of course, being a developer, I tend to side with the developers on this equation.

At the same time, though, I really like the architecture and look of Qt. And I understand Trolltech's need to make money and fund development of Qt. (Remember, I side with the developer). And they do have a pretty good Eclipse/CDT integration for Qt. And the commercial licenses aren't that much of a barrier if you're already used to paying for the libraries you use.

But I always secretly hoped that circumstances would change and we could use Qt without worrying about licensing. Does the transaction with Nokia lead to that circumstance. Apparently not according to the news release and letters to Trolltech's community. But I really think that if Qt had a free commercial license, like the Eclipse Public License, the whole KDE/Qt versus GTK wars would have ended long ago and we'd have peace and unity on the Linux desktop, and maybe on mobile devices too. At the very least, you would have seen a Qt SWT port.

C Dj Trance

Believe or not I'm a big fan of hard rock music. It started with Iron Maiden, etc. in the 80s and moved to Nirvana, etc. in the 90's and with The Cure all throughout. It's what I call my "angry music". Not that I'm an angry guy, but I just love music that challenges me that way. But these days, no one knows how to play guitar anymore so I need to find my angry music elsewhere.

I have to thank my former colleague Johnny C for introducing me to Trance music. Electronic music has also always been an side interest of mine, but I'm a guitar hack first (a favorite memory recently is jamming with Eclipse's very own Steve Northover one night). However, I'm a geek firstest, so any chance to involve my passion for music with computers, I'll all over it. And I just love the rhythms and textures of Trance.

So I had this notion that I could make my own Trance music. There's is actually some good low cost digital audio workstation (DAW) software solutions, including a decent one called REAPER, that I've been playing with to see if I want to get into it. The challenge with these solutions is finding the right software synthesizers and effects to make it all sound good. But I was floored by the number of free DAW plug-ins out there. It's quite the huge underground ecosystem.

The main facilitator of this seems to be a free SDK put out by Steinberg called Virtual Studio Technology or VST. (BTW, there's a Microsoft equivalent called DXi, of course). It was build for their own DAW solution, but they openned up the licensing to allow anyone to take advantage of it, like REAPER. I'm not sure if that makes business sense, but it is helping me get interested in digital music so I may become a customer one day.

I checked out the SDK and even got the sample plug-in to compile using Wascana. Unfortunately, they've released a new version of the SDK that isn't backwards compatible so I couldn't try the plug-in in REAPER which doesn't support it yet. But I was able to launch the plug-in in the test host that comes with the SDK. Everything seemed to work except for the bitmap resources since I don't think we have the gnu resource compiler hooked up in our managed build integration. And unfortunately I ran into trouble getting it to debug at all under gdb. Yet another reason to get the Microsoft debug APIs integrated I guess.

But it does look like the CDT would be a nice IDE for applications like this. With the kind of processor power and multimedia assembly instructions you need to make these audio plug-ins work well in large setups, this is another area where I don't see C++ going away. The experience on Windows could be improved with a nicer Microsoft compiler and debugger integration. And it's a cool way to mix my passion for software with my passion for sound in one place.

24 is the new 20

Well, I'm sitting here typing away looking at my new 24" widescreen monitor. Pidgin running on one side talking to my kind boss who ordered it for me, Internet Exploder on the other with me typing right here, and a monster Eclipse looking at IResource implementations sitting behind them. It's great.

Way back I blogged about my new widescreen laptop and commented on how liberating it was running Eclipse where had no problem seeing the Package/Project Explorer, editors, and Outline View in their full glory. Now at 24" at 1920x1200, it goes to a new level. The only problem is that I have to turn my head now to go between the Outline View and the left edge of the editor. Oh well. I'm sure if I had anything bigger, it might be too big (did I say that?).

And this size of monitor is getting pretty cheep. This is a good one at only $700. The 20" 4:3 monitors we used to druel about were more than that not so long ago. So if you're in the market for a new monitor for working in Eclipse, 24" is highly recommended.

How slow is Java? Not as much as you may think.

I was reading an article on the D programming language (more on that in an upcoming post). At the end of it, the guy claimed it was close in performance to C++. And he used this benchmarking site as evidence. It measures a number of different programming languages on a couple of x86 platforms at performing various algorithms. Most of the algorithms are pretty intense, so it's a good measure of the raw compute power of their runtimes.

Now any such measure is easy to dispute. Did the programmers have sufficient knowledge in the languages to build implementations that would be efficient? They do allow you to play with different weightings for different factors that may be important to you. But the results are interesting non-the-less.

So, a couple of things caught my eye with the default results. First, C++ is faster than C. That I can see if you use C++ inlining a lot which is not always easy to do in C. But it is only slightly faster so I'd call it a draw.

Second, if you preallocate 64MB of heap (-Xms), which we often do, Java is only 1.7 times slower than C++. I think that is a very important result. We often wondered if the CDT's parsers were slow because they were written in Java. The IBM J9 guys said that was crazy talk and these numbers somewhat show their point. Well written Java that really benefits from JIT should be less than 2 times slower than C++. We were looking for a 10 times performance improvement and would probably have been disappointed if we had rewritten everything in C++ (and I mean disappointed in the career limiting aspects of that decision ;).

I don't know whether to fully trust the numbers on this site, but it does reaffirm my belief that Java isn't that much slower than C++. I still don't like Java, though. Show me something as powerful as the Standard Template Library in Java and I might change my mind. Or the 'foreach' from D...

Hey Buddy, Want a Job?

Now that I'm playing manager, certain things occupy my thoughts more than they used to. One of them will be my ability to hire good Eclipse talent as opportunities open up for me to do so. Knowing who I know in the Eclipse community, there is a lot of good talent out there, just none of them really looking for new opportunities. And I'm not the only one who would be interested, I've talked to two other managers who also work for large vendors in the Eclipse community who are struggling finding Eclipse experts.

Now, I wonder if that's just a facet of the industry I am in, i.e., embedded development. The big issue we face is that most of the developers that work in our companies are C/C++ developers, not Java developers let alone Eclipse developers. Not only that, but there is a distinct bias against Java, especially from the guys who have been through the trenches with customers complaining about size/performance in resource critical devices. So needless to say, if we need tools developers, we can no longer really depend on growing them from inside the ranks like we have in the past.

So I wonder what solutions are available to help us poor souls looking for help. Certainly there are job sites out there where potential candidates can post resumes. But with those, I've found it difficult to weed through the masses looking for the right skills. Everyone seems to know enough Eclipse to put it on their listings, but how many know how to make Eclipse plug-ins.

One interesting idea I came up with this weekend is whether having such a job listing site as a part of eclipse.org would be useful. It could be something similar to Plug-in Central that vendors use to advertise their wares. We do have the helpwanted newsgroup, but I'd like to see one where it's more a two way street. Obviously we would need some sort of optional discretion to allow vendors or candidates to be quiet about their searches. But it could make it easier for Eclipse experts and Eclipse managers to find each other.

Android for gamers on the go

I haven't posted much here lately. I guess starting a new job that's to be expected. I'm having a great time, though, and am learning more about install and licensing (the team I'm managing at Wind) than I've ever have. And I think there are some opportunities to do some cool things in this critical area that doesn't get much of the spotlight. And of course, I still have a lot of CDT work I want to do for Ganymede.

At any rate, one thing you will fine me post more about is Google Android. I've mentioned in the past my passing interest in game development. I've never had the opportunity to do any, but with my teenage sons at that ripe video gaming age, I can't help but think of the cool software that goes into these games and how much fun my boys have with it.

And being a development tools kind of guy and Eclipse in particular, I can't help but think that Eclipse would make an awesome environment to build games including everything from modeling characters and building levels to writing the code to make it all happen. That's my dream for Eclipse anyway.

Now the reason I love Android, is that I think it would make a great mobile gaming platform. And the Android gang must think so to since the SDK already comes with OpenGL ES support for 3D rendering with both a native library and a Java layer. It will be interesting to see what game developers can come up with and how well actual hardware will work. But it'll be fun to watch. And it would be really cool if they used Eclipse to build it.

In the meantime, I see that a Russian game developer has ported their 2D game to Android already. For a look at the YouTube video and article, check here.