Ian pointed out this article via Twitter (I starting to get used to Twitter now that I have a client embedded in my iGoogle page). It a discussion by the author about whether community members who take but don't contribute back is good or bad for the health of the community. I think the argument is presented well on both sides, including quotes from our friends Michael Scharf (on the bad side) and Mike Milinkovich (on the good side). I think in the past I've gone on record as saying that it's disappointing when vendors don't contribute back, but that I understand the reasons why. And the author did point out those reasons.
But I think this is an important thing to consider at this stage of Eclipse's life cycle. Eclipse is a mature open source project. Vendors who were there in the early days have had long enough to figure out whether their investment in open source reaped the return they were hoping. And in these economic times, you'll see these vendors faced with the decision on what to do with that investment. Good, you do more; bad, you reduce.
And I think the results are a mixed bag. Clearly for the CDT, the growth of the community was phenomenal. I see a lot of recognition that the CDT is now the defacto standard C/C++ IDE, especially in the embedded space. Most vendors there have dropped competing products and jumped on the bandwagon. Customers are well aware of the CDT and that plays into their purchasing decisions.
But there's one factor of the "leeching" that somewhat scares me. What ends up happening is that it appears that you are investing in making your competitors' products better, while they are not reciprocating. That doesn't make much business sense. But that is a factor that's starting to get added to the equation. ROI is one thing, but supporting the competition while getting less in return is a nasty consequence.
The conclusion of the article really drove home that point for me. "..., the culture of collaboration, which is really the ideal of open source, doesn't run very deep in most companies. Institutions, as Woods pointed out, simply aren't wired that way -- yet." I think more effort needs to be put into changing the wiring...
Monday, June 01, 2009
Sunday, May 31, 2009
Catch the Wave
It's a cold and rainy day today. We just had the freakiest hale storm I've seen in quite a while. It's a good day to be inside. While watching the Jays get pounded by the Red Sox (man, they Jays need better pitching), I watched the Google Wave keynote from last week's Google IO. BTW, I finally found a good use for twitter as I followed a couple of guys I know who were there who kept us up to date on what was going on. That was good because the video didn't show the standing O that the presentors got (it was good but standing O good?)
Anyway, I am quite impressed by the workflows and concepts behind Wave. If you haven't seen it yet, Wave is really just a good realization of collaboration tooling that we kind of see in IBM's Jazz, but more general. You could also see it as a redesign of e-mail systems to take into account and interface with or replace all the other social networking tools out there. The coolest feature is the real-time collaboration you can do, and of course, the API that allows you to play in this world too.
We've talked about IDE in the cloud a bit in Eclipse and, while not for everyone, I think it has potential. And Google Wave seems like a good framework to make this happen. Add an extension to interact with a server side Eclipse, and you get instant integration with the rest of your collaboration tools. Interesting potential.
But there was something else that struck me. Google is open sourcing pretty much all of this. They want to build Wave as an ecosystem to get as many people working through their browser as possible. I still haven't figure out how that makes Google money, but I'm sure there's a master plan at work there. But one thing you'll notice, is that Google worked for two years behind closed doors before pushing it out. This is the same way IBM put together Eclipse, how QNX pushed out CDT. It happens a lot.
And that got me thinking. Is this the only way innovation happens, i.e., in closed environments. How much innovation really happens in open source projects or at least how efficient is it? Realistically, it's a lot less than you'd think. Innovation happens when get get a crack team together in a highly collaborative environment where you don't need to spend time working with a community of diverse interests. So while open source helps make a technology popular, I don't think it's possible to create it there. But maybe that's stating the obvious.
Anyway, I am quite impressed by the workflows and concepts behind Wave. If you haven't seen it yet, Wave is really just a good realization of collaboration tooling that we kind of see in IBM's Jazz, but more general. You could also see it as a redesign of e-mail systems to take into account and interface with or replace all the other social networking tools out there. The coolest feature is the real-time collaboration you can do, and of course, the API that allows you to play in this world too.
We've talked about IDE in the cloud a bit in Eclipse and, while not for everyone, I think it has potential. And Google Wave seems like a good framework to make this happen. Add an extension to interact with a server side Eclipse, and you get instant integration with the rest of your collaboration tools. Interesting potential.
But there was something else that struck me. Google is open sourcing pretty much all of this. They want to build Wave as an ecosystem to get as many people working through their browser as possible. I still haven't figure out how that makes Google money, but I'm sure there's a master plan at work there. But one thing you'll notice, is that Google worked for two years behind closed doors before pushing it out. This is the same way IBM put together Eclipse, how QNX pushed out CDT. It happens a lot.
And that got me thinking. Is this the only way innovation happens, i.e., in closed environments. How much innovation really happens in open source projects or at least how efficient is it? Realistically, it's a lot less than you'd think. Innovation happens when get get a crack team together in a highly collaborative environment where you don't need to spend time working with a community of diverse interests. So while open source helps make a technology popular, I don't think it's possible to create it there. But maybe that's stating the obvious.
Friday, May 29, 2009
Bjorn says "I had more to say but..."
And he turned off comments on his blog basically forcing me to put the comment here. The CDT committers know I refer to Bjorn and his use of Jedi mind tricks. And I'm falling into it again, making my thoughts visible on my own blog instead of hiding it in his comments page. You're Jedi mind tricks don't work on me, well, actually they do...
There are a lot of good things happening at Eclipse, and that you can't argue with. This week's demo of e4 self-hosting is definitely something very cool. Using the CDT in my hobby time this week doing something intense has helped me realize what a good thing we have and the great work that the contributors have put together. So as much nay saying and navel gazing we've done in recent weeks, things aren't all that bad.
But for those of us who have been around a while, the excitement at Eclipse is certainly well below the levels of those early days. I'll never forget those early EclipseCons and looking around at all the vendor positioning going on, trying to grab a piece of the spotlight. It was pretty wacky, and really fun for this lowly developer from Saskatchewan to be a part of.
But Eclipse has grown up. As Bjorn says, it is what it is. It ain't all that bad. Is it as good as we'd individually like it to be? No, it's not. That's the frustration you see. Especially as us old timers start to deal with that reality. But I'm proud to be associate with Eclipse and it has rewarded me well. And I think that's true for many.
So we keep plugging away. People will come and go, Bjorn included, and Eclipse lives on because it still meets that need that sparked the excitement in the early days. And we should all be proud of that.
There are a lot of good things happening at Eclipse, and that you can't argue with. This week's demo of e4 self-hosting is definitely something very cool. Using the CDT in my hobby time this week doing something intense has helped me realize what a good thing we have and the great work that the contributors have put together. So as much nay saying and navel gazing we've done in recent weeks, things aren't all that bad.
But for those of us who have been around a while, the excitement at Eclipse is certainly well below the levels of those early days. I'll never forget those early EclipseCons and looking around at all the vendor positioning going on, trying to grab a piece of the spotlight. It was pretty wacky, and really fun for this lowly developer from Saskatchewan to be a part of.
But Eclipse has grown up. As Bjorn says, it is what it is. It ain't all that bad. Is it as good as we'd individually like it to be? No, it's not. That's the frustration you see. Especially as us old timers start to deal with that reality. But I'm proud to be associate with Eclipse and it has rewarded me well. And I think that's true for many.
So we keep plugging away. People will come and go, Bjorn included, and Eclipse lives on because it still meets that need that sparked the excitement in the early days. And we should all be proud of that.
Java is making me dumb
Sorry everyone who loves Java. But if you're a regular reader, you know about my love/hate relationship with Java. I hate it because I can't do the things I can do in C++ with it. But I love it because I'm making a pretty good living using it on Eclipse-based projects. So I deal.
Now, in my playing with Android and doing JNI development with it and OpenGL ES, I found myself immersed again in C++ for the first time in a very long time and loving it. One of the things you do with graphic programming is matrix multiplication. So I thought it would be cool if I created a Matrix class and an operator overload for the multiplication operator. So I could write code like this:
M4 myTransform = baseTransform * currTransform;
with all of these things as 4x4 matrices. Much less typing, no? :). So I coded it up and for the life of me I couldn't figure out why it wasn't working. Well, after mucking with it and trying different combinations I remembered something Bjorn Stoustrup mentioned in the C++ "bible". If you aren't doing anything special in your constructors, don't provide them. The compiler will take care of it for you and will do a better job of it than you could. So I removed them, and bingo, it worked!
Man I felt dumb, and at bit of a loss as to how I forgot how to do intense C++ programming. Clearly doing Java almost full time like I do, I'm out of practice. Now, you could argue that that's why people should stay away from C++, because it's too complicated. And, sure, it's not for the meek.
But I was trying to show the incredible benefits the gcc compiler gives you with performance over Java, especially in mobile where the JIT's aren't up to snuff (and Dalvik in particular doesn't even have one) and gcc can optimize using extended hardware capabilities like SIMD instructions. So there is a method to my madness and you put up with the pain to reap the rewards. Anyway, more on that after the Ottawa demo camp. Don't want to spoil the show :).
Now, in my playing with Android and doing JNI development with it and OpenGL ES, I found myself immersed again in C++ for the first time in a very long time and loving it. One of the things you do with graphic programming is matrix multiplication. So I thought it would be cool if I created a Matrix class and an operator overload for the multiplication operator. So I could write code like this:
M4 myTransform = baseTransform * currTransform;
with all of these things as 4x4 matrices. Much less typing, no? :). So I coded it up and for the life of me I couldn't figure out why it wasn't working. Well, after mucking with it and trying different combinations I remembered something Bjorn Stoustrup mentioned in the C++ "bible". If you aren't doing anything special in your constructors, don't provide them. The compiler will take care of it for you and will do a better job of it than you could. So I removed them, and bingo, it worked!
Man I felt dumb, and at bit of a loss as to how I forgot how to do intense C++ programming. Clearly doing Java almost full time like I do, I'm out of practice. Now, you could argue that that's why people should stay away from C++, because it's too complicated. And, sure, it's not for the meek.
But I was trying to show the incredible benefits the gcc compiler gives you with performance over Java, especially in mobile where the JIT's aren't up to snuff (and Dalvik in particular doesn't even have one) and gcc can optimize using extended hardware capabilities like SIMD instructions. So there is a method to my madness and you put up with the pain to reap the rewards. Anyway, more on that after the Ottawa demo camp. Don't want to spoil the show :).
Tuesday, May 26, 2009
Tim Sweeney Interview, old story new
Gamasutra, a gaming news site, published an interview they did with the legendary Tim Sweeney of Epic Games, the Unreal and Gears of War gang. You can read it here:
http://www.gamasutra.com/view/feature/4035/from_the_past_to_the_future_tim_.php
I've read interviews from him before and have always appreciated the honest look he gives of the industry. I was even more impressed when he showed up on some of the "making of" material of my boys' Gears of War II game. He is quite the geek, but man he knows his stuff technically and he understands the business, which is a hard to find in a single person.
In this interview, the thing that really struck me was how he started Epic out of his parents house and dorm room in between jobs mowing lawns and his school work. Back in the 80's and early 90's the software industry really was driven by independent developers like this. The big guys at the time just weren't nimble enough to work with all the new technology coming along. It was an exiting time.
Zooming ahead 15-20 years, it seemed that this environment, the ability of independent developers to build software by themselves or in small teams and produce applications that sell enough to provide them with a decent living were long gone. But I'm starting to see that change. The are now a few stories of guys building iPhone apps in the same way Tim did back then and making it "rich". And as the number of mobile platforms grow and with app stores becoming an easy way for these independent developers to sell their wares, I'm sure there's a next generation Tim Sweeney coming alive out there.
http://www.gamasutra.com/view/feature/4035/from_the_past_to_the_future_tim_.php
I've read interviews from him before and have always appreciated the honest look he gives of the industry. I was even more impressed when he showed up on some of the "making of" material of my boys' Gears of War II game. He is quite the geek, but man he knows his stuff technically and he understands the business, which is a hard to find in a single person.
In this interview, the thing that really struck me was how he started Epic out of his parents house and dorm room in between jobs mowing lawns and his school work. Back in the 80's and early 90's the software industry really was driven by independent developers like this. The big guys at the time just weren't nimble enough to work with all the new technology coming along. It was an exiting time.
Zooming ahead 15-20 years, it seemed that this environment, the ability of independent developers to build software by themselves or in small teams and produce applications that sell enough to provide them with a decent living were long gone. But I'm starting to see that change. The are now a few stories of guys building iPhone apps in the same way Tim did back then and making it "rich". And as the number of mobile platforms grow and with app stores becoming an easy way for these independent developers to sell their wares, I'm sure there's a next generation Tim Sweeney coming alive out there.
Monday, May 25, 2009
Building Communities
There's been a couple of times now that presentations I've made have been recorded for posterity. I don't usually listen to them, mainly because I'm worried it really sucked and I felt embarrassed. But the main stage presentation I gave at EclipseCon was different on many levels. And having just finished listening to it, I'm glad it's been captured. It's available at Eclipse Live here:
http://live.eclipse.org/node/739
The title of the presentation is "The Rise and Fall and Rise of the CDT: Lessons on Building Communities". It is a very personal look at the history of the CDT and the lessons I learned about building communities through the roller-coaster ride I've been on for the last 7 years working on the CDT.
This little presentation is my proudest moment of my career. I put a lot on the line with it and you can tell at the beginning I was a bit nervous about that. But listening to it today, I am very happy with how it went.
If you are curious about my philosophies on working in open source communities, or just curious why I'm such a crazy man, here's an open window into my soul. And there is some humour to keep things from getting too serious.
http://live.eclipse.org/node/739
The title of the presentation is "The Rise and Fall and Rise of the CDT: Lessons on Building Communities". It is a very personal look at the history of the CDT and the lessons I learned about building communities through the roller-coaster ride I've been on for the last 7 years working on the CDT.
This little presentation is my proudest moment of my career. I put a lot on the line with it and you can tell at the beginning I was a bit nervous about that. But listening to it today, I am very happy with how it went.
If you are curious about my philosophies on working in open source communities, or just curious why I'm such a crazy man, here's an open window into my soul. And there is some humour to keep things from getting too serious.
Sunday, May 24, 2009
Common Navigator misses the mark
What's wrong with this picture:
This is a Android project that includes both JDT and CDT natures to build an Android app with a native library using the upcoming Android Native Development Kit. As you can see both JDT and CDT contribute to the list of things in the project. The Resource system would put it's own twist on the project if I hadn't turned it off.
The Common Navigator was a great idea when it was proposed. Have a single navigator framework that projects could contribute to. I have the sense it wasn't meant to handle the use case where you'd want to see a project that that has multiple natures leading to multiple contributors. The result is confusing at best, and embarrassing at the least.
But it's a good example of where the Eclipse dream of interoperability is a bit of a failure. Yes, there is a bug on this (didn't have time to look up the number but one of the CDT committers warned that this was going to happen). And my understanding is that it won't make the cut for 3.5 meaning this behaviour will be seen in commercial products as well, unless the vendors fork and fix it locally. And it's just not the JDT's fault, CDT is helping here too, and not knowing, I wonder if it's something missing from the framework to help co-ordinate this.
It's pretty disappointing and, yes, embarrassing, as I try to get the Android community to use the CDT for this style of application. There's no reason to create separate projects for Java and C++. Everything else is working fine in the one project. They'll just have to make sure the expand the right version of the src folder to find their Java source, at least there's icons that differentiate it, unlike the assets and res folders.
This is a Android project that includes both JDT and CDT natures to build an Android app with a native library using the upcoming Android Native Development Kit. As you can see both JDT and CDT contribute to the list of things in the project. The Resource system would put it's own twist on the project if I hadn't turned it off.
The Common Navigator was a great idea when it was proposed. Have a single navigator framework that projects could contribute to. I have the sense it wasn't meant to handle the use case where you'd want to see a project that that has multiple natures leading to multiple contributors. The result is confusing at best, and embarrassing at the least.
But it's a good example of where the Eclipse dream of interoperability is a bit of a failure. Yes, there is a bug on this (didn't have time to look up the number but one of the CDT committers warned that this was going to happen). And my understanding is that it won't make the cut for 3.5 meaning this behaviour will be seen in commercial products as well, unless the vendors fork and fix it locally. And it's just not the JDT's fault, CDT is helping here too, and not knowing, I wonder if it's something missing from the framework to help co-ordinate this.
It's pretty disappointing and, yes, embarrassing, as I try to get the Android community to use the CDT for this style of application. There's no reason to create separate projects for Java and C++. Everything else is working fine in the one project. They'll just have to make sure the expand the right version of the src folder to find their Java source, at least there's icons that differentiate it, unlike the assets and res folders.
Friday, May 22, 2009
Mobile, the new TRS-80
I'm embarrassed to tell this story, but it gives a sense of where I come from. I was in high school in the early 80's. This is when the personal computer world had mystique. You had the Commodore PET's, VIC 20's, and 64's. You had Radio Shack's TRS-80. Before I made enough money to buy my own Coleco Adam, I used to head down to the local Radio Shack in Regina, not far from Wascana Lake, BTW, and the sales guys there would let me type away at the TRS-80 they had there. This was where my passion for computer programming got it's first taste of fuel. It was great.
The Coleco Adam which ran Apple Basic was where I got my first full time experience and wrote my first program, a simulation of the old Stock Ticker board game. For university, I convinced my parents to lend me money for a Commodore Amiga 500. That was amazing. It was also my first experience with the mantra, the best technology doesn't always win and the IBM PC blew Amiga and Apple II and the TRS-80 et al away. It wasn't until I had kids that I finally broked down and bought my first PC.
Anyway, I'm telling this story because I see that same mystique in the new mobile platforms that we have today. You have that same diversity in operating systems and user interfaces and hardware shapes and sizes. You have the fight in processors, this time ARM versus Intel Atom, that we had back then with Intel's 8086 versus the 6502 and Motorola 6800. Who's going to win? I hope they all tie.
It's an exciting time. Programmers have a whole new set of platforms to build applications for. We've been getting pretty bored building the same old apps for desktops. And now we finally have good development tools that we can use to target any of these platforms (and yes, we need to get Eclipse working for iPhone app developers). For the Ottawa Demo Camp, I plan on showing what I'm doing with Android using their Java environment along with the CDT for native libraries. The productivity I'm getting is exactly what we hoped.
I'm having a blast. Programming for Android reminds me a lot of those days I spent down at the Radio Shack with that TRS-80. This time, though I'll probably hedge my bets and take a look at the other platforms out there as well, like iPhone, Blackberry, Nokia's Qt on Symbian, and even at Moblin, which I plan on getting up and running on my Via Artigo box.
Can you tell? I'm glad that mystique is back...
The Coleco Adam which ran Apple Basic was where I got my first full time experience and wrote my first program, a simulation of the old Stock Ticker board game. For university, I convinced my parents to lend me money for a Commodore Amiga 500. That was amazing. It was also my first experience with the mantra, the best technology doesn't always win and the IBM PC blew Amiga and Apple II and the TRS-80 et al away. It wasn't until I had kids that I finally broked down and bought my first PC.
Anyway, I'm telling this story because I see that same mystique in the new mobile platforms that we have today. You have that same diversity in operating systems and user interfaces and hardware shapes and sizes. You have the fight in processors, this time ARM versus Intel Atom, that we had back then with Intel's 8086 versus the 6502 and Motorola 6800. Who's going to win? I hope they all tie.
It's an exciting time. Programmers have a whole new set of platforms to build applications for. We've been getting pretty bored building the same old apps for desktops. And now we finally have good development tools that we can use to target any of these platforms (and yes, we need to get Eclipse working for iPhone app developers). For the Ottawa Demo Camp, I plan on showing what I'm doing with Android using their Java environment along with the CDT for native libraries. The productivity I'm getting is exactly what we hoped.
I'm having a blast. Programming for Android reminds me a lot of those days I spent down at the Radio Shack with that TRS-80. This time, though I'll probably hedge my bets and take a look at the other platforms out there as well, like iPhone, Blackberry, Nokia's Qt on Symbian, and even at Moblin, which I plan on getting up and running on my Via Artigo box.
Can you tell? I'm glad that mystique is back...
Wednesday, May 20, 2009
Wascana is over
Yes, I'm giving up on the dream. For most of my time working on the CDT, I've tried to help make it the C/C++ IDE for anything and everything. A lot of people flocked to it naturally mainly in areas where it had no real competition, especially in the embedded space. And lately I'm seeing a lot of uptake in the Linux desktop space as well. And looking at the vendors contributing to the CDT, it matches what they were investing in. And that's great. We've really met, and at times exceeded, the objectives we set out for ourselves.
But I always yearned for one more. The Windows desktop space. It was Microsoft Visual Studio 6 that got me into using IDEs and built my passion to work on one. And the CDT has always had Visual Studio as one of the bars we were working towards reaching. And as Microsoft reduced their investment on Visual C++, we were able to meet that bar and scream past it. I remember reading an article where they were struggling with indexing, an area where the CDT is now really strong. That was a proud moment for me.
Yet to really show we've met the bar, I felt we needed to have a real IDE distribution that had equivalent functionality to Visual Studio. That meant including a compiler and a strong SDK for building Windows applications. Wascana was my attempt at building that IDE. And I had a lot of great feedback on it. People loved the simplicity of a single install that gave them everything to do their work.
But a few things have happened since I started Wascana. Mainly, I switched jobs and am no longer working 100% on the CDT. In fact it is much less than that, probably just enough to fulfil my duties as project lead. So any work on Wascana would have to be on my own time.
And I need to be honest with myself and you, the passion I once had for CDT for Windows (which should have been the name of this project) is waning. As I blogged about last, my attention is turning to mobile. There are lot of really cool mobile platforms out or about to be released and there is a lot of opportunity in that space to make a difference. CDT for Windows, not so much. It's too much of a fight. A fight I don't have the time or the passion to fight any more.
I know a number of people will be disappointed by that. And to those who still want to see something like Wascana, I encourage you to carry the torch. I'm not going anywhere and would be happy to provide guidance. And who knows, maybe one of the vendors that I know sell a Wascana type thing will make their work more readily available.
Anyway, I'm very excited about what's happening in the mobile space. CDT has a huge roll there so my passion for that does not wane. In fact, there is one area that I think we really need to fix, i.e. CDT's build system, that can really help mobile app developers. And if I stop pushing for an internal builder and a fancy build model that I felt we needed to match Visual Studio and instead just provide a good Makefile editor and template engine, maybe we can dig out of that hole too.
But I always yearned for one more. The Windows desktop space. It was Microsoft Visual Studio 6 that got me into using IDEs and built my passion to work on one. And the CDT has always had Visual Studio as one of the bars we were working towards reaching. And as Microsoft reduced their investment on Visual C++, we were able to meet that bar and scream past it. I remember reading an article where they were struggling with indexing, an area where the CDT is now really strong. That was a proud moment for me.
Yet to really show we've met the bar, I felt we needed to have a real IDE distribution that had equivalent functionality to Visual Studio. That meant including a compiler and a strong SDK for building Windows applications. Wascana was my attempt at building that IDE. And I had a lot of great feedback on it. People loved the simplicity of a single install that gave them everything to do their work.
But a few things have happened since I started Wascana. Mainly, I switched jobs and am no longer working 100% on the CDT. In fact it is much less than that, probably just enough to fulfil my duties as project lead. So any work on Wascana would have to be on my own time.
And I need to be honest with myself and you, the passion I once had for CDT for Windows (which should have been the name of this project) is waning. As I blogged about last, my attention is turning to mobile. There are lot of really cool mobile platforms out or about to be released and there is a lot of opportunity in that space to make a difference. CDT for Windows, not so much. It's too much of a fight. A fight I don't have the time or the passion to fight any more.
I know a number of people will be disappointed by that. And to those who still want to see something like Wascana, I encourage you to carry the torch. I'm not going anywhere and would be happy to provide guidance. And who knows, maybe one of the vendors that I know sell a Wascana type thing will make their work more readily available.
Anyway, I'm very excited about what's happening in the mobile space. CDT has a huge roll there so my passion for that does not wane. In fact, there is one area that I think we really need to fix, i.e. CDT's build system, that can really help mobile app developers. And if I stop pushing for an internal builder and a fancy build model that I felt we needed to match Visual Studio and instead just provide a good Makefile editor and template engine, maybe we can dig out of that hole too.
Sunday, May 17, 2009
It's Android Time
Well, I've had a lot of fun trying different things with embedded Linux and creating simple platforms. The idea was to help hobbyists and students start using CDT for building embedded applications. We have the remote download and launcher (using RSE) and gnu cross compiler support in the upcoming CDT 6.0 to help make it a real force in this area.
That work was pretty much all on hobby time. And it was fun to see it working. But I was describing that the hobby was just like work just on my own time. And my wife make a point that really hit home, "yeah, it's like work but you don't get paid". Uh, yeah.
That and there are already a lot of platforms out there for hobbyists to get starting using Eclipse for embedded development. And one of those platforms has a Market place that allows you to sell the little apps that you can make. Hobby, that pays. Hmmm.
Of course, the platform I'm talking about is Android. It has a great set of Eclipse tooling for writing apps. Yes, it's Java, and yes I bash Java regularly. But it gets the job done. And I think I have something to offer Android. Myself and a few others out on the webisphere have figured out how to build JNI libraries for Android. That gives you the best of both worlds. JDT for Java, CDT for the native libraries. You probably only need native libraries for compute intensive tasks that you can use the underlying hardware to help accelerate. But at times that is a need.
And building native libraries is pretty easy. Do a google search for Android Build System and you'll see a general description of it and the special Android.mk file you need to provide. You need to build your library in a subdirectory under the Android source tree. But once it's there you can create a CDT project that points to it. "make mymodule showcommands" and you're off to the races. And CDT's scanner discovery will even pick out the include path from the gcc/g++ commands.
Now I'm not sure how the native libraries work on real devices. It may be prohibited due to security concerns. So I'd like to try it on one before I push the idea too far. Rogers up here in Canada is finally getting Android phones in June, the same ones as T-mobile. I'll have to invest in one and see. But going through the SDK docs, I am getting the feeling this will be pretty rewarding, in more ways than one ;)
So what does this mean for my work on Wascana, which also competes for my hobby time? I'm still keen on it, and my new strategy of "stealing" the RPM contents from Fedora will allow that to take less time. But it comes back to what I was saying in my previous blog entry. It's a big burden trying to promote CDT for Windows development. Sometimes I feel alone and I wonder if anyone really cares. It's a burden I'm getting tired of carrying. Hopefully someone will step up and help, or some vendor will come in and fund some of it. We'll see.
That work was pretty much all on hobby time. And it was fun to see it working. But I was describing that the hobby was just like work just on my own time. And my wife make a point that really hit home, "yeah, it's like work but you don't get paid". Uh, yeah.
That and there are already a lot of platforms out there for hobbyists to get starting using Eclipse for embedded development. And one of those platforms has a Market place that allows you to sell the little apps that you can make. Hobby, that pays. Hmmm.
Of course, the platform I'm talking about is Android. It has a great set of Eclipse tooling for writing apps. Yes, it's Java, and yes I bash Java regularly. But it gets the job done. And I think I have something to offer Android. Myself and a few others out on the webisphere have figured out how to build JNI libraries for Android. That gives you the best of both worlds. JDT for Java, CDT for the native libraries. You probably only need native libraries for compute intensive tasks that you can use the underlying hardware to help accelerate. But at times that is a need.
And building native libraries is pretty easy. Do a google search for Android Build System and you'll see a general description of it and the special Android.mk file you need to provide. You need to build your library in a subdirectory under the Android source tree. But once it's there you can create a CDT project that points to it. "make mymodule showcommands" and you're off to the races. And CDT's scanner discovery will even pick out the include path from the gcc/g++ commands.
Now I'm not sure how the native libraries work on real devices. It may be prohibited due to security concerns. So I'd like to try it on one before I push the idea too far. Rogers up here in Canada is finally getting Android phones in June, the same ones as T-mobile. I'll have to invest in one and see. But going through the SDK docs, I am getting the feeling this will be pretty rewarding, in more ways than one ;)
So what does this mean for my work on Wascana, which also competes for my hobby time? I'm still keen on it, and my new strategy of "stealing" the RPM contents from Fedora will allow that to take less time. But it comes back to what I was saying in my previous blog entry. It's a big burden trying to promote CDT for Windows development. Sometimes I feel alone and I wonder if anyone really cares. It's a burden I'm getting tired of carrying. Hopefully someone will step up and help, or some vendor will come in and fund some of it. We'll see.
Thursday, May 14, 2009
Too few cooks
On Planet Eclipse we've had some harsh but healthy discussion on how Eclipse could be better organized for success. There are probably little things that need to be done, but at the end, I think the conclusion is that the Foundation staff are doing a pretty good job and Eclipse is organized to accomplish what it was intended to, to provide an open ecosystem for companies to work together on Eclipse platform technologies.
But I am still very worried about Eclipse. And the main problem I am seeing is that there are too few people making the wheels turn, especially as we push Galileo out the door. I figure if we removed probably 3 or 4 people from the equation, Galileo would stop dead in it's tracks and the release wouldn't happen. That is scary in my books. Even on the CDT, if I didn't do the countdown to releases, as I've done for the past 5 years or so, the CDT wouldn't release either. Or at the very least, someone else would have to jump in. And I won't even start with the e4 flexible resource project which currently has one part time guy actually doing code.
That's a pretty big burden for those few. And give the number of commercial vendors that rely on Eclipse technologies, I wonder if it's fair. The good news is that these few people have a lot of passion and are very focused on making Eclipse releases happen. So it will be a success. But understaffed projects is a chronic problem at Eclipse and that's where I fear it's future.
Maybe this fear comes from my own situation where I've been reduced to pretty much working on CDT in my hobby time plus a few hours here and there in my day job. But I know a lot of people in the same position and really wonder how we'll accomplish our goals in the upcoming year for Eclipse. That's the reality we need to figure out how to deal with and improve. Eclipse governance problems is incredibly minor compared to that.
But I am still very worried about Eclipse. And the main problem I am seeing is that there are too few people making the wheels turn, especially as we push Galileo out the door. I figure if we removed probably 3 or 4 people from the equation, Galileo would stop dead in it's tracks and the release wouldn't happen. That is scary in my books. Even on the CDT, if I didn't do the countdown to releases, as I've done for the past 5 years or so, the CDT wouldn't release either. Or at the very least, someone else would have to jump in. And I won't even start with the e4 flexible resource project which currently has one part time guy actually doing code.
That's a pretty big burden for those few. And give the number of commercial vendors that rely on Eclipse technologies, I wonder if it's fair. The good news is that these few people have a lot of passion and are very focused on making Eclipse releases happen. So it will be a success. But understaffed projects is a chronic problem at Eclipse and that's where I fear it's future.
Maybe this fear comes from my own situation where I've been reduced to pretty much working on CDT in my hobby time plus a few hours here and there in my day job. But I know a lot of people in the same position and really wonder how we'll accomplish our goals in the upcoming year for Eclipse. That's the reality we need to figure out how to deal with and improve. Eclipse governance problems is incredibly minor compared to that.
Friday, May 08, 2009
MinGW Cross for Linux
I mentioned in my last entry that building stuff on my laptop leaves scorch marks on my legs (if you haven't read it, that won't make sense). This is especially true when building in my Windows VM. But I figure it wasn't so bad when building from within Fedora itself. And since I knew from my experience on the MinGW mailing lists that the developers there mainly use Linux as their build hosts, I figured that maybe a better path towards building what I need for Wascana would be do it that way to. Build a cross-compiler that ran on Linux and built Windows libraries.
Then I remembered that I ran into Andrew Overholt from Red Hat and he was excited to let me know that they were working hard on mingw packages for Fedora. That was before my Fedora days so I kinda blew it off, as "sounds good, I guess" (sorry Andrew!). So when I googled to find out how to build a cross compiler for MinGW, of course, I ran into the work at Fedora that he was talking about. And it blew me away. Not only are they packaging up the cross compiler, they're also packaging up a pretty thorough list of libraries to help you build Windows apps, many more than I was thinking of for Wascana.
So that's led me to wonder, since I'm now a Fedora fanboy :P, why not sync Wascana up to these packages. That way, whether your building your apps from Linux or from Windows using Wascana, you have the same library set available to you. I should also make sure the versions line up for the toolchain so that there are no ABI issues on the C++ side (which probably isn't a real problem anyway).
And interestingly enough, it brings into play the Cross GCC compiler integration that I build for the tutorial I gave at EclipseCon which I have just contributed to CDT 6.0. I should make sure you can use it easily in this environment too.
The team building the cross mingw stuff for Fedora have made all the decisions and I can extract what I need from their RPMs to install into Wascana. In fact a number of the packages already have zip files ready to grab with p2. Thank you Fedora team!
Then I remembered that I ran into Andrew Overholt from Red Hat and he was excited to let me know that they were working hard on mingw packages for Fedora. That was before my Fedora days so I kinda blew it off, as "sounds good, I guess" (sorry Andrew!). So when I googled to find out how to build a cross compiler for MinGW, of course, I ran into the work at Fedora that he was talking about. And it blew me away. Not only are they packaging up the cross compiler, they're also packaging up a pretty thorough list of libraries to help you build Windows apps, many more than I was thinking of for Wascana.
So that's led me to wonder, since I'm now a Fedora fanboy :P, why not sync Wascana up to these packages. That way, whether your building your apps from Linux or from Windows using Wascana, you have the same library set available to you. I should also make sure the versions line up for the toolchain so that there are no ABI issues on the C++ side (which probably isn't a real problem anyway).
And interestingly enough, it brings into play the Cross GCC compiler integration that I build for the tutorial I gave at EclipseCon which I have just contributed to CDT 6.0. I should make sure you can use it easily in this environment too.
The team building the cross mingw stuff for Fedora have made all the decisions and I can extract what I need from their RPMs to install into Wascana. In fact a number of the packages already have zip files ready to grab with p2. Thank you Fedora team!
Thursday, May 07, 2009
At home in my Fedora
Well, it's been about a month now and I'm starting to really feel at home with Fedora on my main machine, the Dell D830 laptop. The longer you go, the more packages you install that you find you need and eventually you end up with something pretty decent. My biggest issue was dealing with 32-bit apps and missing the 32-bit libs they need to run which you don't get when your in 64-bit mode (I have 4GB RAM and want to use it all). But that's pretty solvable if not time consuming. And then there's the never ending issue of docking and undocking the laptop, going from single screen to my second 24" LCD at work to my alternate second 22" at home. I still have to reboot to get the thing to recognize the second screens, and I even get the occasional hang when coming out of standby. But I'm dealing with that.
There are some things that just rock. I've been playing with the VIA Artigo I got at ESC a couple of years ago and building embedded images and toolchains and kernels and libraries is a dream with the tools available on Linux. There's no beating "-o loop" to peek at and create a file system image (just remember to type the right /dev name when doing a mkdosfs, doh!). Not to mention having all the utils and libs necessary to build cross compilers and such. And I've played with both buildroot and OpenEmbedded which are things you only want to do on Linux.
One thing I am learning though is that anything compute intensive probably shouldn't be done on a laptop. I think I'm melting my video chip as the external screen goes into fits as the disk and CPU get busy. Not to mention the scorch marks on my legs trying to watch the NHL playoffs and build a cross gcc at the same time. So I'm starting to use my Dell desktop at work more where I've learned the slickness of "ssh -Y". You can't do that on Windows.
But I still have a Windows XP image running in VirtualBox for those times I do need Windows. I still use Outlook for work. There's no beating it for the high volumes I get and the Calendar is top notch, and despite Evolution's attempt at Exchange integration, it's not quite ready for prime time. And of course, I need Windows to finish up Wascana 1.0 which almost ready for beta trials with Galileo. And I have a partition open to try it on Windows 7 (especially now that I mkdosfs'ed over my old Windows install, same doh!).
But I can't remember how many times I've gone between the Windows VM and Linux and forgot which one I was in. That is telling me that the Linux desktop isn't all that bad. I still hate the fonts (been complaining about that for years) and the multi-screen situation, but the rest is making it worth it. Highly recommended, at least if you're someone like me.
There are some things that just rock. I've been playing with the VIA Artigo I got at ESC a couple of years ago and building embedded images and toolchains and kernels and libraries is a dream with the tools available on Linux. There's no beating "-o loop" to peek at and create a file system image (just remember to type the right /dev name when doing a mkdosfs, doh!). Not to mention having all the utils and libs necessary to build cross compilers and such. And I've played with both buildroot and OpenEmbedded which are things you only want to do on Linux.
One thing I am learning though is that anything compute intensive probably shouldn't be done on a laptop. I think I'm melting my video chip as the external screen goes into fits as the disk and CPU get busy. Not to mention the scorch marks on my legs trying to watch the NHL playoffs and build a cross gcc at the same time. So I'm starting to use my Dell desktop at work more where I've learned the slickness of "ssh -Y". You can't do that on Windows.
But I still have a Windows XP image running in VirtualBox for those times I do need Windows. I still use Outlook for work. There's no beating it for the high volumes I get and the Calendar is top notch, and despite Evolution's attempt at Exchange integration, it's not quite ready for prime time. And of course, I need Windows to finish up Wascana 1.0 which almost ready for beta trials with Galileo. And I have a partition open to try it on Windows 7 (especially now that I mkdosfs'ed over my old Windows install, same doh!).
But I can't remember how many times I've gone between the Windows VM and Linux and forgot which one I was in. That is telling me that the Linux desktop isn't all that bad. I still hate the fonts (been complaining about that for years) and the multi-screen situation, but the rest is making it worth it. Highly recommended, at least if you're someone like me.
Monday, May 04, 2009
Navel Gazing
Man, we're sure doing a lot of navel gazing on Planet Eclipse about the future of Eclipse, thanks a lot to Bjorn's own navel gazing. I'm not sure why we are doing this since I am sure that Mike and the gang do that quite a lot themselves already and I'm not sure we're helping.
Anyway, I think it is a natural process to go through at this stage of Eclipse's life. Since the original consortium was created back in November 2001 (according to wikipedia, but I think that's pretty accurate), the software industry has changed a lot as you'd expect in 7+ years. Open source was pretty new back then and it was a bold move by IBM to start this thing. And, at the time, having an organization to promote and manage the growth Eclipse was critical to it's success. It made open source friendly to companies that feared it and it really pushed them into a new way of thinking.
Fast forward to today, there's no doubting that open source is now, not only accepted, but for many companies, it's the preferred way of working, especially on commodity platforms. Companies that used to play commercially in that space have moved on to higher ground or found niches to sell their wares, or disappeared all together, or are Microsoft. Open source is a commercial force, no matter what the Free Software people would like to think.
So what does this mean for Eclipse? I'm not sure. And that's why I am appreciating the navel gazing going on. What should it mean?
That made me wonder about Linux. Yes, it has a Foundation, but in the timeline of Linux, that's actually a fairly new development. Linux survived for years as a free software project. But if you look at the latest stats that I found (Apr 2008), you'll see that more that 3/4's of Linux development is done by developers that work for commercial vendors that have a vested interest in it. Surprisingly 9% of that development is by IBM.
I think it's pretty easy to imagine that if horrible things came to pass and the Foundation ceased to exist, Eclipse would live on. And for the same reasons Linux has. Too many companies have a vested interest in it to leave it for dead. And yes, the larger companies would want some sort of insurance against bad things, so you'll always need a Foundation, just like Linux has.
But how influential should that Foundation and the members that support it be in the day to day operation of Eclipse developers? Right now, it's a lot. The freedom of developers is very restricted relative to other open source projects. For some, it's even more restrictive than what their employers allow. And, sure, it's less restrictive than many commercially sponsored open source projects (OpenOffice comes to mind). But where are we on the open source project health scale? Or does that matter at all? Are things really all that bad right now?
No, no solution to the navel gazing here, and I guess more questions than answers. But it is a good time to think about it. Or maybe, I'm just doing my own navel gazing...
Anyway, I think it is a natural process to go through at this stage of Eclipse's life. Since the original consortium was created back in November 2001 (according to wikipedia, but I think that's pretty accurate), the software industry has changed a lot as you'd expect in 7+ years. Open source was pretty new back then and it was a bold move by IBM to start this thing. And, at the time, having an organization to promote and manage the growth Eclipse was critical to it's success. It made open source friendly to companies that feared it and it really pushed them into a new way of thinking.
Fast forward to today, there's no doubting that open source is now, not only accepted, but for many companies, it's the preferred way of working, especially on commodity platforms. Companies that used to play commercially in that space have moved on to higher ground or found niches to sell their wares, or disappeared all together, or are Microsoft. Open source is a commercial force, no matter what the Free Software people would like to think.
So what does this mean for Eclipse? I'm not sure. And that's why I am appreciating the navel gazing going on. What should it mean?
That made me wonder about Linux. Yes, it has a Foundation, but in the timeline of Linux, that's actually a fairly new development. Linux survived for years as a free software project. But if you look at the latest stats that I found (Apr 2008), you'll see that more that 3/4's of Linux development is done by developers that work for commercial vendors that have a vested interest in it. Surprisingly 9% of that development is by IBM.
I think it's pretty easy to imagine that if horrible things came to pass and the Foundation ceased to exist, Eclipse would live on. And for the same reasons Linux has. Too many companies have a vested interest in it to leave it for dead. And yes, the larger companies would want some sort of insurance against bad things, so you'll always need a Foundation, just like Linux has.
But how influential should that Foundation and the members that support it be in the day to day operation of Eclipse developers? Right now, it's a lot. The freedom of developers is very restricted relative to other open source projects. For some, it's even more restrictive than what their employers allow. And, sure, it's less restrictive than many commercially sponsored open source projects (OpenOffice comes to mind). But where are we on the open source project health scale? Or does that matter at all? Are things really all that bad right now?
No, no solution to the navel gazing here, and I guess more questions than answers. But it is a good time to think about it. Or maybe, I'm just doing my own navel gazing...
Wednesday, April 29, 2009
Writing Eclipse Plug-ins in C++
Well, not the entire plug-in. But I thought that would get your attention.
After spending a while mulling around with embedded Linux and Qt and qemu and thinking about OpenGL ES and how I'd build a handheld console or set top box that had a 3D graphical environment using something like Clutter, I'm now trying to figure out what kind of tools you'd need for such a world where 3D graphics was common place.
That led me back to something I tried a couple of years ago, trying to get OpenGL rendering in Eclipse. The idea was to provide a complete tool suite for building 3D games in Eclipse. We have C/C++ covered with the CDT. You might also want some 3D modeling tools for building characters and scenes. Why couldn't that be in the Eclipse environment as well. Yes, these are usually done by different people, but I'm thinking of the small, independent developer shops where that may not be true.
The OpenGL canvas widget in SWT makes this pretty easy. I installed the LWJGL library that allows you to make OpenGL calls in Java and I got the Snippet that draws a torus spinning around in an SWT window running. Very cool.
But as I often mentioned here, I "hate" Java (well, it's pretty much a love/hate relationship since I still pick it for my day job on Eclipse technologies). I want to have the option of using native CPU capabilities like SIMD instructions you get with the SSE family instructions. So I'd prefer to do as much as possible in C++.
So I did that. I got rid of the LWJGL code and replaced it with my own native library that implemented an init, resize, and draw routine. Essentially this is all the code needed to render into the canvas and you can do the rest with a few Java calls to set the current context and to swap the buffers. Very very cool. Now to get this running in an Eclipse editor and we're off to the races.
Here's a snapshot of what I have so far. And yeah, it looks like the LWJGL version, but, trust me, all the OpenGL code is in C++ behind the three native methods:
After spending a while mulling around with embedded Linux and Qt and qemu and thinking about OpenGL ES and how I'd build a handheld console or set top box that had a 3D graphical environment using something like Clutter, I'm now trying to figure out what kind of tools you'd need for such a world where 3D graphics was common place.
That led me back to something I tried a couple of years ago, trying to get OpenGL rendering in Eclipse. The idea was to provide a complete tool suite for building 3D games in Eclipse. We have C/C++ covered with the CDT. You might also want some 3D modeling tools for building characters and scenes. Why couldn't that be in the Eclipse environment as well. Yes, these are usually done by different people, but I'm thinking of the small, independent developer shops where that may not be true.
The OpenGL canvas widget in SWT makes this pretty easy. I installed the LWJGL library that allows you to make OpenGL calls in Java and I got the Snippet that draws a torus spinning around in an SWT window running. Very cool.
But as I often mentioned here, I "hate" Java (well, it's pretty much a love/hate relationship since I still pick it for my day job on Eclipse technologies). I want to have the option of using native CPU capabilities like SIMD instructions you get with the SSE family instructions. So I'd prefer to do as much as possible in C++.
So I did that. I got rid of the LWJGL code and replaced it with my own native library that implemented an init, resize, and draw routine. Essentially this is all the code needed to render into the canvas and you can do the rest with a few Java calls to set the current context and to swap the buffers. Very very cool. Now to get this running in an Eclipse editor and we're off to the races.
Here's a snapshot of what I have so far. And yeah, it looks like the LWJGL version, but, trust me, all the OpenGL code is in C++ behind the three native methods:
Monday, April 27, 2009
Planet Eclipse Ego?
I was trying to point a buddy of mine (who actually should know better, but anyway) to Planet Eclipse. He replied, it takes me here: http://en.wikipedia.org/wiki/Planet_Eclipse_Ego. I laughed long and hard.
So is it true? Is there a Planet Eclipse Ego? I'm probably guilty on that a bit. I find myself yearning to post to see my name up on the Planet, instead of just waiting to write something people would actually care about. But almost all the other posts are very informative and I don't see much evidence of any sort of "ego". Not much anyway ;).
BTW, Pat posted a comment on my last blog about being interested to pay a couple of bucks for the CDT if he could get it off an App Store. Maybe that's the answer on how to get more funding for Eclipse development. And it plays inadvertently into Bjorn's suggestion to stop doing builds at Eclipse. If you want Eclipse for free, check it out and build it yourself, just like with most other open source packages. If you want someone to do that for you, belly up to the App Store and get yours for cheap. Hmm...
So is it true? Is there a Planet Eclipse Ego? I'm probably guilty on that a bit. I find myself yearning to post to see my name up on the Planet, instead of just waiting to write something people would actually care about. But almost all the other posts are very informative and I don't see much evidence of any sort of "ego". Not much anyway ;).
BTW, Pat posted a comment on my last blog about being interested to pay a couple of bucks for the CDT if he could get it off an App Store. Maybe that's the answer on how to get more funding for Eclipse development. And it plays inadvertently into Bjorn's suggestion to stop doing builds at Eclipse. If you want Eclipse for free, check it out and build it yourself, just like with most other open source packages. If you want someone to do that for you, belly up to the App Store and get yours for cheap. Hmm...
Saturday, April 25, 2009
App stores, the new economy?
You can't help but appreciate what Apple is doing with it's App Store which recently sold it's one billionth app the other day. That's a lot of apps, and that's a lot of money going from the consumer's pocketbook to the software developer and Apple. Apparently the Apple App Store now has around 35,000 apps listed. A lot of them are free and almost all of them are available for under $10. Certainly accessible to the masses.
Being a software developer, I can't help but envy the guys who are writing these apps. You hear the stories of guys who worked weekends in their basement to make good but simple apps that rake in revenue in the 6 digits in a matter of months. I don't think there are a lot of similar stories, but it does raise the eyebrows.
I'm also not clear how open Apple is with it's development environment. From what I've been told, you have to buy it from them. It's cheap, only $99 to get started. But their environment only runs on Macs of course and the feedback I've been hearing is that their Xcode IDE isn't anything to write home about. And there is interest in bringing Eclipse and the CDT into the picture.
So the question that comes to my mind is whether this success can be replicated by someone else. And, in particular, I'm looking at all these ARM SOCs with 3D graphics and multimedia decoding hardware running embedded Linux. It looks like this should be a no brainer.
Or is it? These platforms are easy to build but technology doesn't make an industry. My son has an iPod Touch and it's a pretty slick device that I'm sure cost Apple more than the $200 we paid for it, or at least they're breaking even on it. No, to build a successful platform, you need an ecosystem and that ranges from the SDK the developer uses, to easy access to their wares via an app store or such, to slick looking hardware consumers crave.
It's no easy task, and I see attempts by the open source source community with platforms such as Open Pandora doomed to failure. It's ugly, clunky, expensive, and lacking that ecosystem to make it successful. I appreciate their attempt. And I think it could work, if you got the big handheld vendors involved to build the hardware, and then used open platforms and tools, such as Linux and Eclipse, to build the apps, and then some one to build and maintain the app store to spread the wealth. But then maybe I'm dreaming or wouldn't someone have done this by now?
Update: I totally forgot about Android and it's app store. But then I'm so totally biased against Java right now, I find it hard to imagine you'll ever see the sleek apps that Apple has. I'm just weird that way. But I would be happy to be proven wrong.
Being a software developer, I can't help but envy the guys who are writing these apps. You hear the stories of guys who worked weekends in their basement to make good but simple apps that rake in revenue in the 6 digits in a matter of months. I don't think there are a lot of similar stories, but it does raise the eyebrows.
I'm also not clear how open Apple is with it's development environment. From what I've been told, you have to buy it from them. It's cheap, only $99 to get started. But their environment only runs on Macs of course and the feedback I've been hearing is that their Xcode IDE isn't anything to write home about. And there is interest in bringing Eclipse and the CDT into the picture.
So the question that comes to my mind is whether this success can be replicated by someone else. And, in particular, I'm looking at all these ARM SOCs with 3D graphics and multimedia decoding hardware running embedded Linux. It looks like this should be a no brainer.
Or is it? These platforms are easy to build but technology doesn't make an industry. My son has an iPod Touch and it's a pretty slick device that I'm sure cost Apple more than the $200 we paid for it, or at least they're breaking even on it. No, to build a successful platform, you need an ecosystem and that ranges from the SDK the developer uses, to easy access to their wares via an app store or such, to slick looking hardware consumers crave.
It's no easy task, and I see attempts by the open source source community with platforms such as Open Pandora doomed to failure. It's ugly, clunky, expensive, and lacking that ecosystem to make it successful. I appreciate their attempt. And I think it could work, if you got the big handheld vendors involved to build the hardware, and then used open platforms and tools, such as Linux and Eclipse, to build the apps, and then some one to build and maintain the app store to spread the wealth. But then maybe I'm dreaming or wouldn't someone have done this by now?
Update: I totally forgot about Android and it's app store. But then I'm so totally biased against Java right now, I find it hard to imagine you'll ever see the sleek apps that Apple has. I'm just weird that way. But I would be happy to be proven wrong.
Wednesday, April 22, 2009
Eclipse is a Drug and other Musings
I haven't written anything here in the last few days and was starting to get the urge to write something, anything. I feel compelled to say something about Bjorn's impending departure from the Eclipse Foundation. But I'm not sure I have much to say. As I mentioned in a previous post, he wears his emotions on his sleeve at times so I wasn't particularly surprised. But I too have a sense of change at Eclipse having been involved for almost seven years now.
Maybe it's because I'm very part time on the CDT in my current job and miss working daily in the open. But I look around the CDT project and see the same is true for many of us. And yeah, the CDT has a lot of functionality today already and we're pretty much in maintenance mode. But there are some cool things we've started talking about, like introducing static code analysis capabilities, and the build system is in much need of a redo. I think there's enough there to generate excitement, I just wish I had more time to promote that. But we'll see what I can do anyway.
And that's the theme of this post. For most of us working on Eclipse, it is very much like a drug. I'm hooked on it. We see a lot of people leaving companies only to find them pop up at another company that also works on Eclipse. We've even seen high profile Eclipse people leave the safety of their mothership to strike out on their own as Eclipse consultants to continue to help feed the Eclipse ecosystem. Once you've been there, you understand why. There are so many good people and so many high profile companies involved at Eclipse, it's certainly a high to be working at it.
So I don't worry about Bjorn leaving. I know he's hooked too and won't go far ;).
BTW, just ran across a blog entry describing how to use the CDT for Linux programming with OpenGL, something I've started to focus on in my hobby time. The instructions are a bit out dated, and I should do some real webinar tutorials on how to do things like this. But I'm fixated on the blog because it has a music player embedded into it and is playing some of my favorite metal bands :). Cool blog marketing trick. BTW, blogging is a drug too ;)
Maybe it's because I'm very part time on the CDT in my current job and miss working daily in the open. But I look around the CDT project and see the same is true for many of us. And yeah, the CDT has a lot of functionality today already and we're pretty much in maintenance mode. But there are some cool things we've started talking about, like introducing static code analysis capabilities, and the build system is in much need of a redo. I think there's enough there to generate excitement, I just wish I had more time to promote that. But we'll see what I can do anyway.
And that's the theme of this post. For most of us working on Eclipse, it is very much like a drug. I'm hooked on it. We see a lot of people leaving companies only to find them pop up at another company that also works on Eclipse. We've even seen high profile Eclipse people leave the safety of their mothership to strike out on their own as Eclipse consultants to continue to help feed the Eclipse ecosystem. Once you've been there, you understand why. There are so many good people and so many high profile companies involved at Eclipse, it's certainly a high to be working at it.
So I don't worry about Bjorn leaving. I know he's hooked too and won't go far ;).
BTW, just ran across a blog entry describing how to use the CDT for Linux programming with OpenGL, something I've started to focus on in my hobby time. The instructions are a bit out dated, and I should do some real webinar tutorials on how to do things like this. But I'm fixated on the blog because it has a music player embedded into it and is playing some of my favorite metal bands :). Cool blog marketing trick. BTW, blogging is a drug too ;)
Monday, April 13, 2009
Fun with Qemu/Qt
Just for fun (and maybe profit), I thought I'd try and get Qt running on the mini ARM Linux setup that I used for my tutorial at EclipseCon. Low and behold, all I had to do was build it with the compiler I got from CodeSourcery for ARM and it worked!
Now there isn't a whole lot of magic here. It's using the Linux framebuffer device that draws to the screen. I'm not sure how it would look on a real device but it looked might fine on qemu. Here's a snapshot of it running on my laptop, which is now solidly Fedora. It's running the browser demo app and has loaded my blog just before I posted this. It took a little while to load and render, but again, it looked pretty good.
Having gotten this far, I start to wonder how much better it would be if I had OpenGL ES emulation in qemu. Would it be faster? Curiosity might kill this cat...
Now there isn't a whole lot of magic here. It's using the Linux framebuffer device that draws to the screen. I'm not sure how it would look on a real device but it looked might fine on qemu. Here's a snapshot of it running on my laptop, which is now solidly Fedora. It's running the browser demo app and has loaded my blog just before I posted this. It took a little while to load and render, but again, it looked pretty good.
Having gotten this far, I start to wonder how much better it would be if I had OpenGL ES emulation in qemu. Would it be faster? Curiosity might kill this cat...
Thursday, April 09, 2009
WolfenQt: Proof in pudding
An update to my previous post. As proof I got it working, here's my blog from earlier today. You can't see the flash since apparently the adobe flash player bypasses the widget set and opens a native window directly. Wonder where it showed up... At any rate, lots of fun. And with OpenGL mode turned on, performs quite nicely and the widgets are quite readable. Click on the picture to see full size. Very nice.
Wednesday, April 08, 2009
Widgets in 3D: WolfenQt
As the shiny balls spin around in my world, Qt has jumped back into the foreground. My Fedora laptop is busy building 4.5 as I write this and slowly catching on fire (man these things get hot when they're busy working). While that was going on, I took another look at how you'd implement Qt widgets in 3D space, kind of like Clutter does in a GTK fashion (mind you I think those are just static 2D images, not widgets).
Low and behold, I came across the Qt Lab Blog entry by someone there who actually has a demo of Qt widgets running in a maze similar to the old id games. He called it WolfenQt. Take a look here:
Very cool! This is exactly how I was hoping it would look and feel. And Qt has the framework to make it happen. I need to do some experimentation with it once I my 4.5 compiled to see how much of this is done in OpenGL versus software rendering. Looking at the code it looks like quite a mix of both. But from the video, it looks fast enough. And I do know the marching guy is rendered using OpenGL at least.
This is the kind of innovation I'd love to see. We talk a lot in the Eclipse world about Java thick clients and Browser/Server architectures. But there's still so much more you can do using native APIs that take advantage of all the new hardware acceleration capabilities that today's platform providers are giving us.
And the CDT is such a natural IDE for this new world. With all these new platforms, developers really need a cross platform cross target development environment to work with them all. The goal for my CDT work right now is to show that off and put together IDE packages, like Wascana and maybe something with DSDP for embedded, that can be used in these environments.
Low and behold, I came across the Qt Lab Blog entry by someone there who actually has a demo of Qt widgets running in a maze similar to the old id games. He called it WolfenQt. Take a look here:
Very cool! This is exactly how I was hoping it would look and feel. And Qt has the framework to make it happen. I need to do some experimentation with it once I my 4.5 compiled to see how much of this is done in OpenGL versus software rendering. Looking at the code it looks like quite a mix of both. But from the video, it looks fast enough. And I do know the marching guy is rendered using OpenGL at least.
This is the kind of innovation I'd love to see. We talk a lot in the Eclipse world about Java thick clients and Browser/Server architectures. But there's still so much more you can do using native APIs that take advantage of all the new hardware acceleration capabilities that today's platform providers are giving us.
And the CDT is such a natural IDE for this new world. With all these new platforms, developers really need a cross platform cross target development environment to work with them all. The goal for my CDT work right now is to show that off and put together IDE packages, like Wascana and maybe something with DSDP for embedded, that can be used in these environments.
Tuesday, April 07, 2009
On the future of Eclipse
Another great post by Bjorn on life at Eclipse in the new world and a great follow up by Michael Scharf on his thoughts on major changes needed to get there. These two posts made me think about what I'd like to see as a way to take Eclipse forward into the future.
Bjorn draws up a nice, clean looking "architecture" on how the cycle of value feeds the Eclipse ecosystem. Committer -> Project -> Product -> Profit -> Committer... Unfortunately there's a week point in this cycle which I fear will blow the whole thing up, and that's the assumption that vendors making profit on Eclipse-based products will be compelled to fund Committers working on open source projects feeding those products. I've seen too many vendors in this position not do that.
It's frustrating to see so many products based on the CDT and less than half of them contribute back to improve the CDT. Maybe the existing committers have done so good a job that they don't have to. Or maybe they're not big enough to devote developers to the cause in a significant fashion to justify the cost. What ever the case, we all know how hard it to bring in new contributors. You need to "Create the Need" for them to come. It certainly isn't out of good will, especially in these times.
Assuming the cycle fails all together, how do we ensure Eclipse projects remain healthy with new contributions? Michael brings up a solution that I've wanted to see for a while. He brings it up from an architectural perspective, which is what he does :), but I bring it up from a political perspective. The members should fund a team of core developers to ensure critical Eclipse projects continue to grow. These developers would be vendor neutral other than to follow the wishes of the members. The Foundation can help co-ordinate this but it's really on the Eclipse membership to make it happen.
The best example of this I know is with the Linux Foundation where they state that one of their goals is "Protecting and Supporting Linux Development". Now Linus doesn't work for the Foundation, but the members do fund his work there to ensure he can continue to work full-time and independently on the kernel. I'm not sure how well this is working in practice, especially with people other than Linus. But it's worthy of a look.
Interestingly enough, a lot of the members of the Linux Foundation are also members of the Eclipse Foundation. But, would such a policy work at Eclipse?
Bjorn draws up a nice, clean looking "architecture" on how the cycle of value feeds the Eclipse ecosystem. Committer -> Project -> Product -> Profit -> Committer... Unfortunately there's a week point in this cycle which I fear will blow the whole thing up, and that's the assumption that vendors making profit on Eclipse-based products will be compelled to fund Committers working on open source projects feeding those products. I've seen too many vendors in this position not do that.
It's frustrating to see so many products based on the CDT and less than half of them contribute back to improve the CDT. Maybe the existing committers have done so good a job that they don't have to. Or maybe they're not big enough to devote developers to the cause in a significant fashion to justify the cost. What ever the case, we all know how hard it to bring in new contributors. You need to "Create the Need" for them to come. It certainly isn't out of good will, especially in these times.
Assuming the cycle fails all together, how do we ensure Eclipse projects remain healthy with new contributions? Michael brings up a solution that I've wanted to see for a while. He brings it up from an architectural perspective, which is what he does :), but I bring it up from a political perspective. The members should fund a team of core developers to ensure critical Eclipse projects continue to grow. These developers would be vendor neutral other than to follow the wishes of the members. The Foundation can help co-ordinate this but it's really on the Eclipse membership to make it happen.
The best example of this I know is with the Linux Foundation where they state that one of their goals is "Protecting and Supporting Linux Development". Now Linus doesn't work for the Foundation, but the members do fund his work there to ensure he can continue to work full-time and independently on the kernel. I'm not sure how well this is working in practice, especially with people other than Linus. But it's worthy of a look.
Interestingly enough, a lot of the members of the Linux Foundation are also members of the Eclipse Foundation. But, would such a policy work at Eclipse?
Sunday, April 05, 2009
The Rise of the User Community
I'm a big Bjorn fan. I've gotten to know him pretty well in my years of involvement with Eclipse. There is no mistaking his passion for open source communities and he's like me, he wears his emotions on his sleeve when things aren't going as well as they could. I'm really enjoying his series on the State of Eclipse. Most of his points I totally agree with based on my experience with CDT, e.g., the need for Diversity and the continuing battle between the User and Vendor communities over the need of an Eclipse product that users can count on, where as I stated in the comments, this is an area that is fundamentally broken at Eclipse.
However, I can't agree that his solution of relying on the members to provide free distributions of Eclipse to replace the distros available at eclipse.org, is the right solution. I'll go further and say it won't even work. As I also stated in the comments, the members that produce commercial IDEs do so in competition with the free distros from Eclipse.org. Making a free distro available from their web sites and supported by them makes no business sense, and knowing sales people as I do, they'll veto it immediately to protect their revenue. Some companies may differ and that's the only hope I see for it.
And there's another reason why the distros at eclipse.org are important. There is a growing list of large User companies that are beginning to contribute to Eclipse to support the free distribution with their user base. You'll notice that the CDT has committers from Google and Ericsson, both of which are examples of this. Without their contributions, the CDT would certainly be worse off. I also met with another such large vendor at EclipseCon who also promised as their developers get up to speed they'll be contributing.
For the CDT, this is the most promising area of growth in the contributor community, and these guys rely on the distros from Eclipse.org. I'm not about to shoot myself in the foot and even if the Foundation put a stop to this (which Mike assures us won't happen), I'd still make a C/C++ IDE available from the CDT store.
It's been a great debate and that's what's so great about open source communities. Everyone has the freedom to state their opinion, Bjorn included. Take advantage of that and think about what they are saying. You might find yourself changing your mind. But don't do it in this case ;).
However, I can't agree that his solution of relying on the members to provide free distributions of Eclipse to replace the distros available at eclipse.org, is the right solution. I'll go further and say it won't even work. As I also stated in the comments, the members that produce commercial IDEs do so in competition with the free distros from Eclipse.org. Making a free distro available from their web sites and supported by them makes no business sense, and knowing sales people as I do, they'll veto it immediately to protect their revenue. Some companies may differ and that's the only hope I see for it.
And there's another reason why the distros at eclipse.org are important. There is a growing list of large User companies that are beginning to contribute to Eclipse to support the free distribution with their user base. You'll notice that the CDT has committers from Google and Ericsson, both of which are examples of this. Without their contributions, the CDT would certainly be worse off. I also met with another such large vendor at EclipseCon who also promised as their developers get up to speed they'll be contributing.
For the CDT, this is the most promising area of growth in the contributor community, and these guys rely on the distros from Eclipse.org. I'm not about to shoot myself in the foot and even if the Foundation put a stop to this (which Mike assures us won't happen), I'd still make a C/C++ IDE available from the CDT store.
It's been a great debate and that's what's so great about open source communities. Everyone has the freedom to state their opinion, Bjorn included. Take advantage of that and think about what they are saying. You might find yourself changing your mind. But don't do it in this case ;).
Saturday, April 04, 2009
Putting on my Fedora
Well, I did it, I finally did it. I ordered a 320GB drive and set up a dual boot situation with my old Windows install and my spanking brand new Fedora 10 on the rest of the disk. So far so good. It wasn't a perfect process, including a 4 hour shrink of my NTFS partition. But I'm up and running. And I have an out to go back if things go bad, but I have a feeling I won't.
I have a Dell D830 and had to install the Broadcom wireless driver and the nVidia driver for my NVS 140M graphics chip. Now, since these aren't under open source licenses, you have to get them from other sources, in my case rpmfusion.org. This is part of what sets Fedora apart from Ubuntu. With Ubuntu, it's a lot easier to set this up. You know you can mix GPL and !GPL and it's OK ;). At any rate, I deal with it since I feel Fedora is a bit crisper, especially for those of us who think they know what they're doing.
So why would I bother doing this? With Eclipse, Windows is a pretty fine development environment. The command line environments there are abysmal, but that's why we work hard on ensuring that you can do all your work from inside Eclipse. But that's probably it. I want to get back into an environment where command line is king (I used HP and Sun workstations long before becoming a Windows developer) and get a better feeling for what development life is like there. That and as I've mentioned before here, Linux is just the best environment for building embedded Linux platforms which is my hobby as of late.
Anyway, we'll see how long I last here before running back to Windows. As I have it, it's not too far away just in case, just over there on /dev/sda1 and in a VM coming soon.
I have a Dell D830 and had to install the Broadcom wireless driver and the nVidia driver for my NVS 140M graphics chip. Now, since these aren't under open source licenses, you have to get them from other sources, in my case rpmfusion.org. This is part of what sets Fedora apart from Ubuntu. With Ubuntu, it's a lot easier to set this up. You know you can mix GPL and !GPL and it's OK ;). At any rate, I deal with it since I feel Fedora is a bit crisper, especially for those of us who think they know what they're doing.
So why would I bother doing this? With Eclipse, Windows is a pretty fine development environment. The command line environments there are abysmal, but that's why we work hard on ensuring that you can do all your work from inside Eclipse. But that's probably it. I want to get back into an environment where command line is king (I used HP and Sun workstations long before becoming a Windows developer) and get a better feeling for what development life is like there. That and as I've mentioned before here, Linux is just the best environment for building embedded Linux platforms which is my hobby as of late.
Anyway, we'll see how long I last here before running back to Windows. As I have it, it's not too far away just in case, just over there on /dev/sda1 and in a VM coming soon.
Wednesday, April 01, 2009
Twitter is the future
I guess twitter is the next great thing in communication:
http://www.guardian.co.uk/media/2009/apr/01/guardian-twitter-media-technology
http://www.guardian.co.uk/media/2009/apr/01/guardian-twitter-media-technology
Monday, March 30, 2009
EclipseCon notes and git
Well, I'm back at my day job at Wind and am doing a little reflection on what happened last week at EclipseCon. Despite the rumored lower attendence, I met with pretty much as many people as I do every year, maybe even slightly more. And hopefully that'll translate into growth in the CDT community.
And I guess my talk on building communities was a little over the top on the subject of project "takers" that I had a number of people come up to me and apologize and offer to contribute in the future. I certainly didn't mean to offend or criticize. I just wanted to prepare project contributors that there are vendors and people who are happy to take your work for free and not give anything back. And, while that's frustrating, with open source licensing there's nothing you can really do about it but be mentally prepared to see it happen.
The one area where I saw a very interesting rise in momentum was with distributed version control at Eclipse and git in particular. It started with discussions at the councils on Sunday where it became obvious that we need significant community interest and willingness of the projects to drive this home to justify the significant cost to the Foundation. There were a couple of BOFs and panels that I missed but it sounds from Karl's post that the activity was significant enough for the Foundation to start putting a plan together. Very cool!
The more I talk to people and dig into it, I think git and DVCS in general is probably one of the most significant technologies driving change in the way we work on software development projects since objects invaded our world. As evidence of that, the thought of distributed source repositories opens the door to the IDE in the Cloud. The Cloud could be built around git repos and if I need to work disconnected, or work with command line tools, I just clone it onto my laptop and merge back later. And being the old "curmudgeon" C/C++ embedded tools guy, that's a significant admission...
And I guess my talk on building communities was a little over the top on the subject of project "takers" that I had a number of people come up to me and apologize and offer to contribute in the future. I certainly didn't mean to offend or criticize. I just wanted to prepare project contributors that there are vendors and people who are happy to take your work for free and not give anything back. And, while that's frustrating, with open source licensing there's nothing you can really do about it but be mentally prepared to see it happen.
The one area where I saw a very interesting rise in momentum was with distributed version control at Eclipse and git in particular. It started with discussions at the councils on Sunday where it became obvious that we need significant community interest and willingness of the projects to drive this home to justify the significant cost to the Foundation. There were a couple of BOFs and panels that I missed but it sounds from Karl's post that the activity was significant enough for the Foundation to start putting a plan together. Very cool!
The more I talk to people and dig into it, I think git and DVCS in general is probably one of the most significant technologies driving change in the way we work on software development projects since objects invaded our world. As evidence of that, the thought of distributed source repositories opens the door to the IDE in the Cloud. The Cloud could be built around git repos and if I need to work disconnected, or work with command line tools, I just clone it onto my laptop and merge back later. And being the old "curmudgeon" C/C++ embedded tools guy, that's a significant admission...
Thursday, March 26, 2009
IDE in the Cloud
There's been a lot of talk at EclipseCon here about the "IDE in the Cloud". I missed it but apparently the Mozilla Bespin demo at the e4 talk was quite impressive. It is easy to set up, and it's pretty fast as a code editor. I guess that makes sense since browsers have been heavily optimized for fast display of textual and graphical content. So I have to admit, it's led me to reconsider this technology. Rational tried this many years ago, remember Catapulse?, to build hosted development environments. The idea, and the company, collapsed in the high-tech bust of 2001. Maybe they were just too early.
But as we start to rely on the cloud, what happens when the sky's are clear? I just heard Kevin McGuire say that, hey, my e-mail is on the server, why shouldn't my code be there too. I use Outlook and Thunderbird in a mode that downloads my e-mail to my machine so I can access it disconnected. I don't always have access to the cloud. Until the cloud is omni-present, through things like metropolitan wireless schemes, and cheep, $10/day at my hotel wasn't cheep, then I don't see it really taking off as the typical way you do software development.
I just worry that the whole "Cloud" paradigm is being pushed by the people that can profit most from it, not from an inherit need of potential users.
But as we start to rely on the cloud, what happens when the sky's are clear? I just heard Kevin McGuire say that, hey, my e-mail is on the server, why shouldn't my code be there too. I use Outlook and Thunderbird in a mode that downloads my e-mail to my machine so I can access it disconnected. I don't always have access to the cloud. Until the cloud is omni-present, through things like metropolitan wireless schemes, and cheep, $10/day at my hotel wasn't cheep, then I don't see it really taking off as the typical way you do software development.
I just worry that the whole "Cloud" paradigm is being pushed by the people that can profit most from it, not from an inherit need of potential users.
Wednesday, March 25, 2009
CDT Code Introspection APIs
I'm just sitting in Markus's talk on the APIs the CDT provides to create code models, ASTs, the Indexer and ways of getting information out of there. These facilities are used to implement features such as content assist and open declaration and searching, etc. And you can use it too for all your static analysis needs. A copy of his presentation is available from the EclipseCon site by following the link to gPublication. It's a great reference on how to get started.
http://www.eclipsecon.org/2009/sessions?id=685
http://www.eclipsecon.org/2009/sessions?id=685
Slides from my Talk on the CDT Community
I'm not sure why the EclipseCon submission system isn't accepting this but here are the slides from my talk on the Rise and Fall and Rise of the CDT, Lessons on Building Communities. I had a lot of fun creating and presenting this talk. I guess it's a passion of mine and people seemed to like it. The slides have few words on it and I'd be happy to give more details if you have any questions. Feel free to add comments here.
Rise and Fall and Rise of CDT
View more presentations from dschaefer1.
Tuesday, March 24, 2009
A Great EclipseCon Already
I've been here at EclipseCon for 48 hours and it's been great already. I've met a lot of people here, like I always do, and it's a good sign that vendors still see Eclipse as important, enough to spend the money in these tough times to send their technical experts.
EclipseCon is an important conference, especially for those who are looking to get started with Eclipse and to grow their expertise. There's probably not enough time to learn it all, but at least you know where to go look when you get home.
It's also important for projects to get the word out about the great work their doing and to grow their community. I was pretty disappointed about the number of submissions I had for the C/C++ category. But we're making due. And it's good to see the number of DSDP contributors here giving talks so we're still showing the world that Eclipse is more than just a Java IDE.
Other things to report:
- work on ObjectiveC is starting and the guys managed to get a prototype running based on CDT late last night.
- the Ada project is looking to reboot.
- e4 talks are the hottest ticket in town
- adding git continues to be controversial and we really need to get a bigger ground swell of contributors who care about making this happen
Anyway, beer time. More later.
EclipseCon is an important conference, especially for those who are looking to get started with Eclipse and to grow their expertise. There's probably not enough time to learn it all, but at least you know where to go look when you get home.
It's also important for projects to get the word out about the great work their doing and to grow their community. I was pretty disappointed about the number of submissions I had for the C/C++ category. But we're making due. And it's good to see the number of DSDP contributors here giving talks so we're still showing the world that Eclipse is more than just a Java IDE.
Other things to report:
- work on ObjectiveC is starting and the guys managed to get a prototype running based on CDT late last night.
- the Ada project is looking to reboot.
- e4 talks are the hottest ticket in town
- adding git continues to be controversial and we really need to get a bigger ground swell of contributors who care about making this happen
Anyway, beer time. More later.
Wednesday, March 18, 2009
POWERVR goes MP
I was just reading up on the news that Imagination Technologies has launched a new generation of their architecture that drives POWERVR. What's POWERVR, you ask? It's a good question, but chances are, if you have a mobile device that has 3D accelerated graphics, it's driven by this hugely popular silicon IP.
The big news is that even they're going multi-core to achieve scalable graphics. They claim they rival the performance of discrete graphics chipsets, which I assume means the nVidias and ATI's of the world. That's a pretty interesting combination when you look at the latest chips that have multi-core ARM processors combined with DSPs (digital signal processors) for audio/video processing, which can then be combined with these powerful 3D cores.
I can imagine some really powerful handheld and other mobile devices based on these things. I just wonder about power consumption, the eternal challenge for mobile developers. We'll see how that plays out, but the power of these things also blurs the gap between mobile and x86 based "netbooks" and even set-top boxen. Interesting times ahead, indeed.
But as good as the hardware is, you still need the software to make them come to life. It's going to be an exciting time for developers that target this market. I just wonder if there are enough of them. This is one area where I'm hoping the Eclipse DSDP and CDT projects can help. We need an easy to setup package to give the students and hobbyists, the future commercial developers for these platforms, the tools they need to get them started. This is something I'd be happy to talk about at EclipseCon and see if we can get a community to start putting this together.
The big news is that even they're going multi-core to achieve scalable graphics. They claim they rival the performance of discrete graphics chipsets, which I assume means the nVidias and ATI's of the world. That's a pretty interesting combination when you look at the latest chips that have multi-core ARM processors combined with DSPs (digital signal processors) for audio/video processing, which can then be combined with these powerful 3D cores.
I can imagine some really powerful handheld and other mobile devices based on these things. I just wonder about power consumption, the eternal challenge for mobile developers. We'll see how that plays out, but the power of these things also blurs the gap between mobile and x86 based "netbooks" and even set-top boxen. Interesting times ahead, indeed.
But as good as the hardware is, you still need the software to make them come to life. It's going to be an exciting time for developers that target this market. I just wonder if there are enough of them. This is one area where I'm hoping the Eclipse DSDP and CDT projects can help. We need an easy to setup package to give the students and hobbyists, the future commercial developers for these platforms, the tools they need to get them started. This is something I'd be happy to talk about at EclipseCon and see if we can get a community to start putting this together.
Sunday, March 15, 2009
Should Wascana get Qt?
I've been working on my EclipseCon talk and tutorial, which I'm really looking forward to now. Especially the talk where I hope to share some of the things I learned being involved with the CDT project for almost seven years now. And I'm hopeful it's useful to others working in open source, especially the things that didn't work as well as I hoped...
Anyway, while doing that, I've started playing with Qt, which was recently released with LGPL as one of the choices for licensing. That eliminates one of the hurdles I have for including it into Wascana, my CDT for Windows distribution. So now the question is, should I include it? Should I also keep wxWidgets? Since the Wascana plan is to become a p2-based distribution, there should be no harm in having both. It's just that I don't use wxWidgets so I'm not sure whether what I'm producing works or not.
Why that matters is because I build the libraries for Wascana myself using the gcc/g++ I distribute with it. I've switched over to tdragon.net as my supplier for gcc, mainly because they (or he?) provides the latest releases from gcc (and the mingw.org community is a bit of a mess). And I want to make sure these libraries are built with the latest and greatest optimization algorithms gcc is providing.
At any rate, I'm learning how to build Qt and it's running right now. I hope it doesn't melt my laptop. They have a ton of example and demo projects that I can use to test so it's a pretty good environment for producing quality distros.
I should also look at their Eclipse plug-ins. They provide an installer for the Windows version which installs into an existing Eclipse. I wish they had a p2 repo that I could use instead. But I'll have to see what they're laying down and understand their licensing to see whether I can make these available in Wascana as well. I still find it weird they have their own IDE, Qt Creator, when it should be pretty easy to put together an Eclipse-based IDE that does almost the same, if not more...
Anyway, while doing that, I've started playing with Qt, which was recently released with LGPL as one of the choices for licensing. That eliminates one of the hurdles I have for including it into Wascana, my CDT for Windows distribution. So now the question is, should I include it? Should I also keep wxWidgets? Since the Wascana plan is to become a p2-based distribution, there should be no harm in having both. It's just that I don't use wxWidgets so I'm not sure whether what I'm producing works or not.
Why that matters is because I build the libraries for Wascana myself using the gcc/g++ I distribute with it. I've switched over to tdragon.net as my supplier for gcc, mainly because they (or he?) provides the latest releases from gcc (and the mingw.org community is a bit of a mess). And I want to make sure these libraries are built with the latest and greatest optimization algorithms gcc is providing.
At any rate, I'm learning how to build Qt and it's running right now. I hope it doesn't melt my laptop. They have a ton of example and demo projects that I can use to test so it's a pretty good environment for producing quality distros.
I should also look at their Eclipse plug-ins. They provide an installer for the Windows version which installs into an existing Eclipse. I wish they had a p2 repo that I could use instead. But I'll have to see what they're laying down and understand their licensing to see whether I can make these available in Wascana as well. I still find it weird they have their own IDE, Qt Creator, when it should be pretty easy to put together an Eclipse-based IDE that does almost the same, if not more...
Tuesday, March 10, 2009
Emulation versus Multi-Platform
Over the last little while, when I could steal away a few minutes from my busy day job as of late, I've been thinking more about open platforms for handheld and set top consoles that makes good use of the 3D hardware that is becoming common place in these platforms. Of course, being open, I'm talking about open source and royalty free APIs like Linux and OpenGL and OpenGL ES.
I've been very excited about the LGPL'ing of the Qt C++ application framework. The programming paradigm is very clean and the library set is huge, including my favorite, the WebKit browser, and, of course, OpenGL support.
One angle I've been following is my other favorite piece of open source software, the qemu CPU emulator. The community is very active there and they're are more and more platforms and hardware components being emulated making it a nice platform to play with some of the concepts I'm thinking of.
But the one critical piece missing is 3D hardware emulation. I would be great if someone could put that together, and given the comments on my previous blog entries, it would be very popular. I could do it, but I have the bigger picture in mind and have some other things I'd like to work on, in particular, a port of the Clutter concepts to Qt (and no, the QGraphicsView is close but not quite what I was thinking of).
Thinking about it tonight, it struck me. Since Qt is multi-platform and the tools I use, gcc and the CDT are multi-platform too, why don't I just start this work on Windows using Wascana, the Eclipse CDT/mingw gcc package I am also trying to work on. I could even use the OpenGL ES emulation libraries that are out there to make sure these ideas work with OpenGL ES, another multi-platform component. And as my work here progresses, I will have the opportunity to use the same tools to make it work on real hardware.
It's this type of environment that motivates my work on the CDT and what makes it so powerful. It's time to put it to work for me.
I've been very excited about the LGPL'ing of the Qt C++ application framework. The programming paradigm is very clean and the library set is huge, including my favorite, the WebKit browser, and, of course, OpenGL support.
One angle I've been following is my other favorite piece of open source software, the qemu CPU emulator. The community is very active there and they're are more and more platforms and hardware components being emulated making it a nice platform to play with some of the concepts I'm thinking of.
But the one critical piece missing is 3D hardware emulation. I would be great if someone could put that together, and given the comments on my previous blog entries, it would be very popular. I could do it, but I have the bigger picture in mind and have some other things I'd like to work on, in particular, a port of the Clutter concepts to Qt (and no, the QGraphicsView is close but not quite what I was thinking of).
Thinking about it tonight, it struck me. Since Qt is multi-platform and the tools I use, gcc and the CDT are multi-platform too, why don't I just start this work on Windows using Wascana, the Eclipse CDT/mingw gcc package I am also trying to work on. I could even use the OpenGL ES emulation libraries that are out there to make sure these ideas work with OpenGL ES, another multi-platform component. And as my work here progresses, I will have the opportunity to use the same tools to make it work on real hardware.
It's this type of environment that motivates my work on the CDT and what makes it so powerful. It's time to put it to work for me.
Thursday, March 05, 2009
Qemu 0.10.0 now available
In a message from Anthony Liguori to the qemu-devel mailing list, "The QEMU team is pleased to announce the availability of the 0.10.0 release. This release has been a year in the making and is the result of almost 3,000 changesets from around 80 developers." The release was quickly put together in the last few days (i.e. in Eclipse terms, there wasn't much of a ramp down). And the resulting build is actually pretty hard to find, at least until it gets propagated to all the mirrors, but it's a milestone anyway.
There's a pretty long list of new targets and hardware emulation. There's also improvements to the VNC support. The biggest news is the new code generator for translating op codes into runnable code. It's called TCG (Tiny Code Generator according to Wikipedia) and removes the dependency qemu had on gcc 3.x, which means it gets to take advantage of the huge performance improvements of gcc 4.x. I think I read somewhere that the Android qemu was running 1.5 times faster thanks to that. And my copy is humming using the gcc 4 I'm integrating into the future Wascana 1.0.
This release is a good sign that the qemu developers are getting serious about formal releases. It's been quite a while since the last release and there has been huge architectural change. That has led to a some difficulties co-ordinating with the other projects that use it, like the kvm Linux virtualization platform. Having quality releases more often will make it easier to get changes from forks into the mainline, which is good for everyone.
For me, it's just good fun to be able to have a virtual platform to try different ideas with C/C++ libraries that target mobile devices that I could easily target to real hardware some day. And I think it's intriguing the Eclipse integrations we could do to make it easier to work in that environment. A lot we have already, like CDT (of course) and the Remote System Explorer for launching, and there is work on more coming from the Tools for mobile Linux project. Interesting indeed.
There's a pretty long list of new targets and hardware emulation. There's also improvements to the VNC support. The biggest news is the new code generator for translating op codes into runnable code. It's called TCG (Tiny Code Generator according to Wikipedia) and removes the dependency qemu had on gcc 3.x, which means it gets to take advantage of the huge performance improvements of gcc 4.x. I think I read somewhere that the Android qemu was running 1.5 times faster thanks to that. And my copy is humming using the gcc 4 I'm integrating into the future Wascana 1.0.
This release is a good sign that the qemu developers are getting serious about formal releases. It's been quite a while since the last release and there has been huge architectural change. That has led to a some difficulties co-ordinating with the other projects that use it, like the kvm Linux virtualization platform. Having quality releases more often will make it easier to get changes from forks into the mainline, which is good for everyone.
For me, it's just good fun to be able to have a virtual platform to try different ideas with C/C++ libraries that target mobile devices that I could easily target to real hardware some day. And I think it's intriguing the Eclipse integrations we could do to make it easier to work in that environment. A lot we have already, like CDT (of course) and the Remote System Explorer for launching, and there is work on more coming from the Tools for mobile Linux project. Interesting indeed.
Tuesday, March 03, 2009
Qt 4.5 Full of Surprises
Qt 4.5 was released today. As expected, it comes with the adoption of the LGPL license which should make Qt free for commercial development if you so choose. I think this will be a huge boost to the adaptability of Qt and hopefully make an impact in the Gnome versus KDE Linux desktop wars (mind you the KDE gang are really shot themselves in the foot when they released 4.x as a planned regression from 3.x).
There were a couple of big surprises that came with the release announcement. First was the discontinuation of Qt's embedded product, formerly and lovingly known as Qtopia, the best product name in the business ;). The plan I understand is to fold that functionality into the Qt mainline releases with the intention of making Qt a truely cross platform API for both desktop and mobile. And they've started by introducing an OpenGL ES paint engine into this release, which if I understand correctly will allow you to use Qt to create apps for mobile devices now.
The other big surprise, isn't really a surprise since I've known about and wondered what was going to happen, but they've released a 1.0 version of their IDE, Qt Creator. It appears they are going forward with this IDE as a key offering, and have released it as LGPL as well. Which means, theoretically, a community could form behind it and it could start to compete with Eclipse. We'll need to do a thorough analysis and understand what it all means. Especially since they also uprev'ed their Eclipse integration and have a beta of their Visual Studio integration available. How does Qt Creator fit into this world?
The only thing that really bugged me in their news release on Qt Creator is their claim that "it provides the first IDE designed specifically for cross-platform development". Uh, guys. The CDT is 7 years old and counting...
There were a couple of big surprises that came with the release announcement. First was the discontinuation of Qt's embedded product, formerly and lovingly known as Qtopia, the best product name in the business ;). The plan I understand is to fold that functionality into the Qt mainline releases with the intention of making Qt a truely cross platform API for both desktop and mobile. And they've started by introducing an OpenGL ES paint engine into this release, which if I understand correctly will allow you to use Qt to create apps for mobile devices now.
The other big surprise, isn't really a surprise since I've known about and wondered what was going to happen, but they've released a 1.0 version of their IDE, Qt Creator. It appears they are going forward with this IDE as a key offering, and have released it as LGPL as well. Which means, theoretically, a community could form behind it and it could start to compete with Eclipse. We'll need to do a thorough analysis and understand what it all means. Especially since they also uprev'ed their Eclipse integration and have a beta of their Visual Studio integration available. How does Qt Creator fit into this world?
The only thing that really bugged me in their news release on Qt Creator is their claim that "it provides the first IDE designed specifically for cross-platform development". Uh, guys. The CDT is 7 years old and counting...
Sunday, March 01, 2009
Way too much fun with qemu
As I've been blogging about lately, I'm getting ready for my EclipseCon tutorial which will walk the attendees through adding support for a cross-compile environment to the CDT. The target of this environment will be qemu running a tiny Linux platform which includes the latest release kernel, busybox, dropbear with sftp-server from OpenSSH, using the free glibc C run-time and gcc cross compile tools from CodeSourcery.
I'm using the default ARM target for the latest qemu which unfortunately has a bug in the FIFO emulation that interfaces with the emulated SecureDigital card where I want my root file system. I asked on the qemu-devel list and someone there sent me a patch they had posted a couple of weeks ago. Checking out the qemu source from svn into the CDT, I was able to fix up the function where this was done and I was quickly up and running with my root file system on the SD card image. Very, very cool!
The next highlight was when I got the ssh components running and I was able to connect to the qemu target using the Remote System Explorer from the Eclipse Target Management project. Also, very, very cool. I want to use RSE and the CDT remote launch to get the results of the build up and running on the target.
So now that I know how to build stuff from the command line, the next step will be the meat of the tutorial, creating the managed build integration for the cross compiler. Of course, you'll have to come to the tutorial to see the result, and actually work with me though the process. But it should be fun!
And now that I've actually started working with qemu in the CDT, I'm starting to get that itch to add 3D graphics support again...
I'm using the default ARM target for the latest qemu which unfortunately has a bug in the FIFO emulation that interfaces with the emulated SecureDigital card where I want my root file system. I asked on the qemu-devel list and someone there sent me a patch they had posted a couple of weeks ago. Checking out the qemu source from svn into the CDT, I was able to fix up the function where this was done and I was quickly up and running with my root file system on the SD card image. Very, very cool!
The next highlight was when I got the ssh components running and I was able to connect to the qemu target using the Remote System Explorer from the Eclipse Target Management project. Also, very, very cool. I want to use RSE and the CDT remote launch to get the results of the build up and running on the target.
So now that I know how to build stuff from the command line, the next step will be the meat of the tutorial, creating the managed build integration for the cross compiler. Of course, you'll have to come to the tutorial to see the result, and actually work with me though the process. But it should be fun!
And now that I've actually started working with qemu in the CDT, I'm starting to get that itch to add 3D graphics support again...
Wednesday, February 25, 2009
Subversive vs. Subclipse
One of the most common Google searches I see in my Feedjit log is from people looking for help in the whole Subversive versus Subclipse debate. It has always dumbfounded me why we have two efforts building Eclipse team providers for Subversion. But I've long given up on fighting that battle.
So as I start to dive into the code for qemu, I found myself in need of making that choice again. Some would say go with Subversive since it's an Eclipse project. I would, but they are mired in provisioning hell with a key component for making it work being on another site due to licensing/IP reasons. That didn't turn me on much so I'm going with Subclipse.
And so far so good, but I've only just checked out the repository. We'll see how it goes if I need to make any patches, and as I keep updating. But my hope is that as it has aged, all the issues I saw a couple of years ago have been addressed.
My heart is still with distributed version control and git in particular. And there is discussions on the qemu list about moving to git. And in particular, I'm very interested in how these team providers work with the CDT and how they work with the changes were doing for e4 on the IResource front. And it's pretty clear that these plug-ins, no matter what version control system they target, need to work well to keep our users and customers engaged.
So as I start to dive into the code for qemu, I found myself in need of making that choice again. Some would say go with Subversive since it's an Eclipse project. I would, but they are mired in provisioning hell with a key component for making it work being on another site due to licensing/IP reasons. That didn't turn me on much so I'm going with Subclipse.
And so far so good, but I've only just checked out the repository. We'll see how it goes if I need to make any patches, and as I keep updating. But my hope is that as it has aged, all the issues I saw a couple of years ago have been addressed.
My heart is still with distributed version control and git in particular. And there is discussions on the qemu list about moving to git. And in particular, I'm very interested in how these team providers work with the CDT and how they work with the changes were doing for e4 on the IResource front. And it's pretty clear that these plug-ins, no matter what version control system they target, need to work well to keep our users and customers engaged.
Sunday, February 22, 2009
CDT 6.0 M5 is Available, BTW
I've been "nose to the grindstone" since the holiday break getting our Wind River Installer out the door, twice. But the good news is that the CDT contributors have been very busy working on CDT 6.0 while I wasn't looking very hard. I have been waiting for the C/C++ IDE Package for M5 to be built. In the meantime, we do have the bits up on the CDT Galileo update site for you to try. Just download the Eclipse Platform or SDK 3.5M5 and add the following URL as an update site:
http://download.eclipse.org/tools/cdt/releases/galileo
Most people will want the "Tools" feature in the "Main" group, which will give you everything you need to work with the gnu toolchain. And yes, the features say 5.1.0, but we're tricking the API tooling with that to keep track of API changes. We'll be 6.0 when we go out the door in June.
I've actually been using CDT 6 for some technical investigations I've been doing lately, the qemu source being one of them. One of the biggest issues with the CDT that we've been fighting forever has been taking projects that have been developed without an IDE, that don't have any real structure to them, bringing them into the CDT, and having our indexer parse and create useful search information for them. And this is especially bad if we can't figure out the include paths to find the header files needed to parse properly.
One common pattern we have noticed with the include path was where all the user specified include paths were actually folders in the workspace. Everything else came from the built-in include path. At the very least, if we could search the workspace when looking for header files that were unresolved, we could probably resolve them.
Well in CDT 6.0M5, that functionality if finally there (thanks, Markus!) and it works superbly! Many of the unresolved headers I saw in this one project I was looking at, which targeted many different OS's, were magically resolved, and features like Open Definition (F3) worked great. Sure, if you have multiple header files with the same name in your project, we may pick the wrong one to resolve, and there will still be issues if you don't specify external include paths, but it's huge step forward for CDT usability.
There are other interesting things in M5, including the Debug Services Framework which has moved from the Device Debugging project to the CDT and should become our "official" debug framework over time. You'll notice the major issue we have with having two debug frameworks when you go to launch (double the launch configs :( ), but we are working on a solution to that.
We're still making great improvements to the CDT as we go. Most of them are under the hood as the feature set we have is working quite well already. And there are still things to clean up, like our managed build system and the underlying build model and the need to integrate that with our debug models. But I know I'm a happy CDT customer myself, and I hope you get a chance to try out CDT 6.0 M5 and give us your feedback.
http://download.eclipse.org/tools/cdt/releases/galileo
Most people will want the "Tools" feature in the "Main" group, which will give you everything you need to work with the gnu toolchain. And yes, the features say 5.1.0, but we're tricking the API tooling with that to keep track of API changes. We'll be 6.0 when we go out the door in June.
I've actually been using CDT 6 for some technical investigations I've been doing lately, the qemu source being one of them. One of the biggest issues with the CDT that we've been fighting forever has been taking projects that have been developed without an IDE, that don't have any real structure to them, bringing them into the CDT, and having our indexer parse and create useful search information for them. And this is especially bad if we can't figure out the include paths to find the header files needed to parse properly.
One common pattern we have noticed with the include path was where all the user specified include paths were actually folders in the workspace. Everything else came from the built-in include path. At the very least, if we could search the workspace when looking for header files that were unresolved, we could probably resolve them.
Well in CDT 6.0M5, that functionality if finally there (thanks, Markus!) and it works superbly! Many of the unresolved headers I saw in this one project I was looking at, which targeted many different OS's, were magically resolved, and features like Open Definition (F3) worked great. Sure, if you have multiple header files with the same name in your project, we may pick the wrong one to resolve, and there will still be issues if you don't specify external include paths, but it's huge step forward for CDT usability.
There are other interesting things in M5, including the Debug Services Framework which has moved from the Device Debugging project to the CDT and should become our "official" debug framework over time. You'll notice the major issue we have with having two debug frameworks when you go to launch (double the launch configs :( ), but we are working on a solution to that.
We're still making great improvements to the CDT as we go. Most of them are under the hood as the feature set we have is working quite well already. And there are still things to clean up, like our managed build system and the underlying build model and the need to integrate that with our debug models. But I know I'm a happy CDT customer myself, and I hope you get a chance to try out CDT 6.0 M5 and give us your feedback.
Thursday, February 19, 2009
Eclipse in the Clouds?
I'm not going to say much with this one. I'll just refer you to the comments people are adding to Boris's blog entry on his work with Mozilla to get an experimental IDE running in a browser with an Eclipse-based server back-end. Is this what developers working in the embedded and desktop space are asking for? Not that I've heard. And neither do a number of the commenters on Boris's article. Some of them are putting it in much prettier words than I could say without getting into trouble...
That's why it is so critical for those of us in the Eclipse community who support such users to make sure Eclipse continues to work well and to improve in the areas that cause them pain. Is the future of enterprise development so different from desktop and embedded that it requires such radical architectures? Maybe so. If that's true, we need to hold our ground and ensure we don't get dragged down a path we can't be going.
That's why it is so critical for those of us in the Eclipse community who support such users to make sure Eclipse continues to work well and to improve in the areas that cause them pain. Is the future of enterprise development so different from desktop and embedded that it requires such radical architectures? Maybe so. If that's true, we need to hold our ground and ensure we don't get dragged down a path we can't be going.
Monday, February 16, 2009
An ARM on Family Day
It's "Family Day" here in Ontario, Canada, and while my one son is over at his buddy's house and my other son is watching game trailers and my wife is out for lunch with the girls, I'm sitting here enjoying the day off. I'm sure we'll do something family-ish later today...
Anyway, I just read about TI's new family of chips, the OMAP4. The big news is that this is the first time TI has jumped on ARM's multi-core bandwagon and the mixture of parts going into these SOCs is quite impressive. You have PowerVR's venerable SXG OpenGL ES 2.0 engine, image processing, and enough power to play 1080p video. As the TI guys says in the LinuxDevices.com article, this type of architecture really will start to blur the lines between smartphones and MIDs (and even makes me wonder about the set-top box market). It looks like we'll be seeing some pretty exciting products ahead.
Speaking of TI, I'm still looking at the BeagleBoard community-based development board kinda thing. The more I look into what the community is doing with it, I really see it's potential as a vehicle for learning embedded development. But I'm cheap, so my attention turned towards whether the qemu emulator could emulate the BeagleBoard so I can run it on my laptop. And apparently someone is working on it. But then I started doing the math. How much is my time worth? Versus forking out the $300 or so to get set up. Makes me think...
Mucking around with all this has led me back to my EclipseCon tutorial on integrating a cross-compiler toolchain for the CDT. I really want to show how easy it is to get up and running with qemu and a cross-compiler and the freely available embedded Linux run-time goodies all under the CDT as the IDE. And given all the hype about ARM and mobile, I think I'll go with ARM as the target CPU. Should be a fun 4 hours, which should be plenty of time to get at least a hello world running. I can't wait and I really hope you can make it too.
Anyway, I just read about TI's new family of chips, the OMAP4. The big news is that this is the first time TI has jumped on ARM's multi-core bandwagon and the mixture of parts going into these SOCs is quite impressive. You have PowerVR's venerable SXG OpenGL ES 2.0 engine, image processing, and enough power to play 1080p video. As the TI guys says in the LinuxDevices.com article, this type of architecture really will start to blur the lines between smartphones and MIDs (and even makes me wonder about the set-top box market). It looks like we'll be seeing some pretty exciting products ahead.
Speaking of TI, I'm still looking at the BeagleBoard community-based development board kinda thing. The more I look into what the community is doing with it, I really see it's potential as a vehicle for learning embedded development. But I'm cheap, so my attention turned towards whether the qemu emulator could emulate the BeagleBoard so I can run it on my laptop. And apparently someone is working on it. But then I started doing the math. How much is my time worth? Versus forking out the $300 or so to get set up. Makes me think...
Mucking around with all this has led me back to my EclipseCon tutorial on integrating a cross-compiler toolchain for the CDT. I really want to show how easy it is to get up and running with qemu and a cross-compiler and the freely available embedded Linux run-time goodies all under the CDT as the IDE. And given all the hype about ARM and mobile, I think I'll go with ARM as the target CPU. Should be a fun 4 hours, which should be plenty of time to get at least a hello world running. I can't wait and I really hope you can make it too.
Tuesday, February 10, 2009
IANAL, BSD, GPL, LGPL, ABCs
Slashdot pointed me to this article by Bruce Parens aimed at clearing some of the air around using GPL and LGPL and commercially licensed product on the same device. Of course, the summary of the article is "Check with your lawyer" as it should be. But I hope it alleviates fears over the FSF licenses that I know people have.
I especially like the description of the motivation that open source developers use to license their software. BSD is a "gift" software license. The developer is giving it to you as a gift, do with it as you wish, just give him some of the credit. LGPL is "non-gift". And I get it. They essentially don't want you using their stuff for free unless you help with it. And then you have GPL, which falls into the category that they just don't want you using their stuff for free, unless you're doing your stuff for free too. This categorization puts a little bit of a human face on it, and I appreciate that.
This also made me think about our situation at Eclipse. It's very difficult to get third party software approved at Eclipse. I'd love to be able to host the GNU tool chain binaries along with the CDT to help new developers get started. Now, I am not a lawyer, but Bruce's article doesn't mention restrictions on distributing binaries, only the run-time requirements. Maybe I'm missing something there, and maybe lawyers are reading more into the license than what I see. So be it, they're professionally responsible for their opinions, I tend not to be.
But there is no mistaking it. Despite whatever legal issues surround open source software, it's popularity can't be denied, especially in the embedded world.
I especially like the description of the motivation that open source developers use to license their software. BSD is a "gift" software license. The developer is giving it to you as a gift, do with it as you wish, just give him some of the credit. LGPL is "non-gift". And I get it. They essentially don't want you using their stuff for free unless you help with it. And then you have GPL, which falls into the category that they just don't want you using their stuff for free, unless you're doing your stuff for free too. This categorization puts a little bit of a human face on it, and I appreciate that.
This also made me think about our situation at Eclipse. It's very difficult to get third party software approved at Eclipse. I'd love to be able to host the GNU tool chain binaries along with the CDT to help new developers get started. Now, I am not a lawyer, but Bruce's article doesn't mention restrictions on distributing binaries, only the run-time requirements. Maybe I'm missing something there, and maybe lawyers are reading more into the license than what I see. So be it, they're professionally responsible for their opinions, I tend not to be.
But there is no mistaking it. Despite whatever legal issues surround open source software, it's popularity can't be denied, especially in the embedded world.
Monday, February 09, 2009
Beagle Board and Eclipse Distros
We had a meeting a few days ago amongst interested parties in an Eclipse IDE distribution for embedded. The idea would be to do something like I'm doing with Wascana which is supposed to make it easy for developers using open source tools, students especially, to get them up and running on Windows, and in turn showcase the features of the CDT in that environment. The idea of doing this for embedded would be to do the same for embedded systems developers and to show case the features of the DSDP project at Eclipse as well as CDT's embedded development support.
One thing I think we noticed quite quickly is the diversity of the embedded community at Eclipse. We have Web services applications for embedded, we have J2ME Java for embedded, we have deeply embedded systems like microkernels and DSPs that have no OS per se, and, of course, we have the more traditional RTOS systems. I think it'll be hard to showcase Eclipse support for all these things in one distro, and maybe it deserves it's a few such distros, or maybe we have RTOS versus not RTOS. It's an interesting initiative and I'm excited to see where it goes.
One of the platforms that came up in the meeting was the Beagle Board. Checking out their web site, it looks like an interesting target for hobbyist and student embedded developers. It's a cheap little board at around $150 US (a little more once you add the needed cables and a power supply to use it properly). The community there is working on getting the Angstrom embedded Linux distro running on the board and there are some cool videos of it working. Don't doubt it, this is being driven by Texas Instruments, who makes the chips for this board, so it's not purely a community driven project, but it looks like an independent community has formed and is running with it.
I think this would be a good choice to target an Eclipse for Embedded distro. I think a case could be made for qemu as well and the various CPUs and boards it emulates. And I assume you'd target Linux for these platforms. But then you open up the questions, which distro do you support, or do you make your own? And what about the other free or quasi-free RTOSes that have Eclipse support. At a minimum you need a cross compile and debug tool chain to integrate Eclipse with but what else would you need?
I get the feeling that this could turn into a pretty big project on it's own. Which, of course means it won't happen without a community behind it and maybe vendors to sponsor it. I'm interested in hearing your opinions on what this all should mean and what you would like to see in an open source Eclipse for Embedded IDE.
One thing I think we noticed quite quickly is the diversity of the embedded community at Eclipse. We have Web services applications for embedded, we have J2ME Java for embedded, we have deeply embedded systems like microkernels and DSPs that have no OS per se, and, of course, we have the more traditional RTOS systems. I think it'll be hard to showcase Eclipse support for all these things in one distro, and maybe it deserves it's a few such distros, or maybe we have RTOS versus not RTOS. It's an interesting initiative and I'm excited to see where it goes.
One of the platforms that came up in the meeting was the Beagle Board. Checking out their web site, it looks like an interesting target for hobbyist and student embedded developers. It's a cheap little board at around $150 US (a little more once you add the needed cables and a power supply to use it properly). The community there is working on getting the Angstrom embedded Linux distro running on the board and there are some cool videos of it working. Don't doubt it, this is being driven by Texas Instruments, who makes the chips for this board, so it's not purely a community driven project, but it looks like an independent community has formed and is running with it.
I think this would be a good choice to target an Eclipse for Embedded distro. I think a case could be made for qemu as well and the various CPUs and boards it emulates. And I assume you'd target Linux for these platforms. But then you open up the questions, which distro do you support, or do you make your own? And what about the other free or quasi-free RTOSes that have Eclipse support. At a minimum you need a cross compile and debug tool chain to integrate Eclipse with but what else would you need?
I get the feeling that this could turn into a pretty big project on it's own. Which, of course means it won't happen without a community behind it and maybe vendors to sponsor it. I'm interested in hearing your opinions on what this all should mean and what you would like to see in an open source Eclipse for Embedded IDE.
Thursday, February 05, 2009
MinGW frustrations
Um, yeah, Wascana 1.0 keeps slipping. Work has been very busy leaving little time for me to work on it, but that should be clearing up in the next few weeks (I hope!). But as I did my testing for the release candidate of CDT 5.0.2, as I expected, I ran headlong into the gdb 6.8 issue that everyone seems to run into. I don't know how many people I see on my Feedjit log searching for: "gdb eclipse No source available for "ntdll!LdrAccessResource()". And I hope those people now find this blog entry instead.
The issue is that before gdb 6.8, there was no way to issue pending breakpoints using the MI protocol we use to talk to gdb. I think it was introduced in 6.7 from the CLI, but that doesn't help us. To support breakpoints in shared libraries, we need to keep retrying to set those breakpoints on every shared library load event. That worked for many years. But now, the break on shared library event in the MinGW gdb 6.8 really messes up the CDT. And it's mainly because it doesn't work in gdb any more.
So the solution is to add support for pending breakpoints, at least into the MinGW debugger target. But, alas, I think that's going to be a lot of work. And given I'm having trouble finding time to even get the p2 support for Wascana done, let alone dive into debug which I don't really have expertise on.
At any rate, the experience is so bad, I'm starting to think of holding off Wascana 1.0 until Galileo in June. I can make the p2 repo available so people can download the same thing I'm testing with. But until this debug issue is resolved, it's not an environment I'm happy to send out to the world.
That and there was an interesting conversation on the mingw users mailing list recently about the state of gcc 4.x for MinGW. I've lost faith that it's ready for prime time as well.
It's enough to make me wish we had a Windows debugger available and to complete our Visual C++ support (wink, wink, nudge, nudge to people who know who they are ;). For now, bear with me.
The issue is that before gdb 6.8, there was no way to issue pending breakpoints using the MI protocol we use to talk to gdb. I think it was introduced in 6.7 from the CLI, but that doesn't help us. To support breakpoints in shared libraries, we need to keep retrying to set those breakpoints on every shared library load event. That worked for many years. But now, the break on shared library event in the MinGW gdb 6.8 really messes up the CDT. And it's mainly because it doesn't work in gdb any more.
So the solution is to add support for pending breakpoints, at least into the MinGW debugger target. But, alas, I think that's going to be a lot of work. And given I'm having trouble finding time to even get the p2 support for Wascana done, let alone dive into debug which I don't really have expertise on.
At any rate, the experience is so bad, I'm starting to think of holding off Wascana 1.0 until Galileo in June. I can make the p2 repo available so people can download the same thing I'm testing with. But until this debug issue is resolved, it's not an environment I'm happy to send out to the world.
That and there was an interesting conversation on the mingw users mailing list recently about the state of gcc 4.x for MinGW. I've lost faith that it's ready for prime time as well.
It's enough to make me wish we had a Windows debugger available and to complete our Visual C++ support (wink, wink, nudge, nudge to people who know who they are ;). For now, bear with me.
Sunday, February 01, 2009
TV's are small, plus a little Clutter
So I was sitting watching my 40" HDTV the other day, and started thinking about why web browsing on a TV pretty much sucks, even with all the pixels you get at 1080i or what have you. And trust me, I tried it with our PS3 and other than watching YouTube videos, it's not a good experience.
But while I was sitting there on my couch (or sofa, depending on your English dialect) a pretty normal distance from the TV, I held my hands up to frame the size of the picture at arms length. Then lowering it to may lap, it struck me. The size of the picture isn't any bigger than a handheld gaming box, maybe slightly bigger than an iPod Touch (as I try to find one for my son's birthday on Thursday :( ).
The reality of the situation is that even with the higher pixel count, you still need to treat set top boxes as mobile, but not mobile, internet devices and entertainment units. And that especially goes for the UI. Don't try running GNOME on it, that's going to be brutal.
So I'm off taking another look at mobile devices and the user interfaces they present. The newest one is the 2.0 alpha release of Moblin, Intel's effort at a Linux distro for mobile internet devices and netbooks running their chips. The video in the LinuxDevices.com article is intriguing, and made me go look at what technology they were using to present their 3D animated GUI.
Well, it turns out to be another open source project called Clutter. They produce a library that abstracts away the grunge of OpenGL and OpenGL ES to build user interfaces. You create Actors that have images and such and declare their animation and event handling and then fire off into an event/display loop. You get pretty cool effects with not too much code.
Now, I have to pick at the choice of GTK as their paradigm mentor and, yes, if you're used to GTK programming, doing Clutter will be natural, but if you're like me and fell in love with the Qt and it's elegant use of C++, then you'll be a little put off. I did find a clutter-qt integration in their repo, so maybe you'll be able to do both in the future.
Someone once said, and I think he lived in Redmond, Washington, that there was no innovation in open source. This is a pretty significant counter to that. This project has been around for a while, sprouting out of the need to add GUIs on top of the new fancy 3D graphic chips appearing in handheld devices. They have a innovative and game changing solution. The just need people to discover them, and Intel, who also happens to be their new boss, is helping with that.
But while I was sitting there on my couch (or sofa, depending on your English dialect) a pretty normal distance from the TV, I held my hands up to frame the size of the picture at arms length. Then lowering it to may lap, it struck me. The size of the picture isn't any bigger than a handheld gaming box, maybe slightly bigger than an iPod Touch (as I try to find one for my son's birthday on Thursday :( ).
The reality of the situation is that even with the higher pixel count, you still need to treat set top boxes as mobile, but not mobile, internet devices and entertainment units. And that especially goes for the UI. Don't try running GNOME on it, that's going to be brutal.
So I'm off taking another look at mobile devices and the user interfaces they present. The newest one is the 2.0 alpha release of Moblin, Intel's effort at a Linux distro for mobile internet devices and netbooks running their chips. The video in the LinuxDevices.com article is intriguing, and made me go look at what technology they were using to present their 3D animated GUI.
Well, it turns out to be another open source project called Clutter. They produce a library that abstracts away the grunge of OpenGL and OpenGL ES to build user interfaces. You create Actors that have images and such and declare their animation and event handling and then fire off into an event/display loop. You get pretty cool effects with not too much code.
Now, I have to pick at the choice of GTK as their paradigm mentor and, yes, if you're used to GTK programming, doing Clutter will be natural, but if you're like me and fell in love with the Qt and it's elegant use of C++, then you'll be a little put off. I did find a clutter-qt integration in their repo, so maybe you'll be able to do both in the future.
Someone once said, and I think he lived in Redmond, Washington, that there was no innovation in open source. This is a pretty significant counter to that. This project has been around for a while, sprouting out of the need to add GUIs on top of the new fancy 3D graphic chips appearing in handheld devices. They have a innovative and game changing solution. The just need people to discover them, and Intel, who also happens to be their new boss, is helping with that.
Friday, January 23, 2009
Can an LGPL Qt give C++ a lift?
Black Duck recently announced their top Rookie Open Source projects for 2008 which using a bit of a weird metric, revealed the top 10 open source projects that were created in 2008 that had the highest number of releases. More releases makes you good? O.K...
Anyway, the most interesting information from their news release was the stats they gathered on what programming languages these new projects were using. To the surprise of many, 47% of them were written in C (C Rules!). That was followed by 28% in Java and 20% in JavaScript. It's pretty interesting there was so much JavaScript usage. And again, these were projects that have just been created. But when you look at it, most open source projects target Linux, and by far the most popular language for Linux is still C.
One thing I noted, though, was that C++ wasn't even mentioned. It could be that they lumped C++ in with C, but I have my doubts. I rarely do see C++ in open source. The large open source game engines, like Ogre and Irrlicht as well as Firefox (of course), are in C++, and OpenOffice is written in every language imaginable including C++, but I see C way, way more.
[Watch out, bad segue ahead...]
I spent part of last weekend taking a deeper look at Qt, with its upcoming spanking new LGPL license. I have to admit I'm a GPL library bigot and kept away from Qt because of that, but boy do I regret that now that I've seen it. It's an incredibly complete C++ library for building apps of all kinds. And it has everything I've been looking at lately, WebKit, JavaScript (well ECMAScript but that's the same thing), and OpenGL, and incredibly smooth integrations between those and many more components.
So as Qt makes this transition, I have a feeling it's going to gain in popularity everywhere. And I think it'll show the power of C++ and pull a lot of the developers writing for the C-based GTK away. Heck even Ubuntu is thinking of switching to it for their mobile platform.
Kudos to Nokia for making this decision. I think it's going to pay dividends for them as developers take a fresh look at a great framework. Which, BTW, means there will be more developers working in the same environment that also happens to run on Nokia's phones ;).
Anyway, the most interesting information from their news release was the stats they gathered on what programming languages these new projects were using. To the surprise of many, 47% of them were written in C (C Rules!). That was followed by 28% in Java and 20% in JavaScript. It's pretty interesting there was so much JavaScript usage. And again, these were projects that have just been created. But when you look at it, most open source projects target Linux, and by far the most popular language for Linux is still C.
One thing I noted, though, was that C++ wasn't even mentioned. It could be that they lumped C++ in with C, but I have my doubts. I rarely do see C++ in open source. The large open source game engines, like Ogre and Irrlicht as well as Firefox (of course), are in C++, and OpenOffice is written in every language imaginable including C++, but I see C way, way more.
[Watch out, bad segue ahead...]
I spent part of last weekend taking a deeper look at Qt, with its upcoming spanking new LGPL license. I have to admit I'm a GPL library bigot and kept away from Qt because of that, but boy do I regret that now that I've seen it. It's an incredibly complete C++ library for building apps of all kinds. And it has everything I've been looking at lately, WebKit, JavaScript (well ECMAScript but that's the same thing), and OpenGL, and incredibly smooth integrations between those and many more components.
So as Qt makes this transition, I have a feeling it's going to gain in popularity everywhere. And I think it'll show the power of C++ and pull a lot of the developers writing for the C-based GTK away. Heck even Ubuntu is thinking of switching to it for their mobile platform.
Kudos to Nokia for making this decision. I think it's going to pay dividends for them as developers take a fresh look at a great framework. Which, BTW, means there will be more developers working in the same environment that also happens to run on Nokia's phones ;).
Thursday, January 15, 2009
J2ME? Why?
I was just reading the slides presented from the kick-off meeting of the Eclipse Mobile Industry Working Group. I believe this is the first working group at Eclipse and I think it's a great concept. Bring groups of companies together that are interested in the same or similar technologies and do some planning. Hopefully that will result in new investments in various Eclipse projects.
Anyway, one of the examples of work environments shown was for a J2ME developer. The first thing that jumped into my head, and of course I'm writing this entry without thinking more so I may come off a bit misinformed here but hey I'm just the dumb C++ guy, but who cares about J2ME any more? With the rich mobile development environments provided with Android, the iPhone, the new Palm Pre, and even Qt for mobile devices, why would you do J2ME development any more. Isn't there much more opportunity for greater riches writing apps for these new and wildly popular environments?
Anyway, feel free to comment and tell me the way it is. And I'm sure the J2ME people over in DSDP are the right people to do that ;), since they know that community. But I am curious about whether the J2ME community is still on the rise, or whether there is a migration happening to these new technologies.
Anyway, one of the examples of work environments shown was for a J2ME developer. The first thing that jumped into my head, and of course I'm writing this entry without thinking more so I may come off a bit misinformed here but hey I'm just the dumb C++ guy, but who cares about J2ME any more? With the rich mobile development environments provided with Android, the iPhone, the new Palm Pre, and even Qt for mobile devices, why would you do J2ME development any more. Isn't there much more opportunity for greater riches writing apps for these new and wildly popular environments?
Anyway, feel free to comment and tell me the way it is. And I'm sure the J2ME people over in DSDP are the right people to do that ;), since they know that community. But I am curious about whether the J2ME community is still on the rise, or whether there is a migration happening to these new technologies.
Wednesday, January 14, 2009
Time to Get Qt?
Now this is interesting. I've mentioned a few times in my blog that the world would be a different place if Qt was given a free commercial friendly license, like LGPL. Of course when Trolltech was an independent company, that would have killed all their revenue. But now that they're owned by Nokia, I guess the time has come for them to make the change.
And I think this will open people's eyes to Qt. It's certainly a very rich framework giving pretty much everything you need to make a truly cross platform application, i.e. #ifdef free. And it's used in some very popular applications like Skype, Google Earth, and the VirtualBox manager. And, of course, it's the foundation of the Linux KDE desktop environment, which has it's devoted fans.
And again, being LGPL, I'd expect to see it used by more commercial applications. Heck, it will now pass my policy and I'll be able to include it in Wascana, and the SWT developers will also be allowed by their lawyers to write the port against it. Who knows...
But as I scout the horizon of desktop and mobile apps, I wonder if the apparent momentum away from C/C++ has become too great for this to make a significant splash, or will it just be a ripple. Maybe my head is too deep in WebKit these days and my view is getting tainted, but the web is slowly taking over. I guess the one thing Qt has going for it is a decent WebKit integration so maybe they can get the best of both worlds. Either way, it's definitely time for me to take a deeper look at Qt (and it's CDT integration, of course ;)).
And I think this will open people's eyes to Qt. It's certainly a very rich framework giving pretty much everything you need to make a truly cross platform application, i.e. #ifdef free. And it's used in some very popular applications like Skype, Google Earth, and the VirtualBox manager. And, of course, it's the foundation of the Linux KDE desktop environment, which has it's devoted fans.
And again, being LGPL, I'd expect to see it used by more commercial applications. Heck, it will now pass my policy and I'll be able to include it in Wascana, and the SWT developers will also be allowed by their lawyers to write the port against it. Who knows...
But as I scout the horizon of desktop and mobile apps, I wonder if the apparent momentum away from C/C++ has become too great for this to make a significant splash, or will it just be a ripple. Maybe my head is too deep in WebKit these days and my view is getting tainted, but the web is slowly taking over. I guess the one thing Qt has going for it is a decent WebKit integration so maybe they can get the best of both worlds. Either way, it's definitely time for me to take a deeper look at Qt (and it's CDT integration, of course ;)).
Monday, January 12, 2009
Palm Pre and WebKit
I've been following the Palm Pre story a bit the last few days. While the technical details are still pretty sparse, it appears that one of my predictions for 2009 is already starting to happen.
My understanding, and I hope it isn't coming from sources who are also using the same technique to guess at the architecture of this thing, is that the UI for the Palm is rendered totally using WebKit. It appears that the applications for this device are written in JavaScript and use HTML and maybe WebKit's SVG support to render the graphics. Hell, maybe it's even using Dojo to make things look really sharp.
If this is true, then it's going to be a great test of how well this architecture works. I have my worries about how JavaScript scales and how easy it is to write traditional GUI apps, even handheld ones, using HTML as a rendering engine. But looking at the screenshots, it looks pretty awesome.
The other thing I notice is that there is a continuing trend of making it very difficult to build native apps that draw on the screen with these things. It started with JavaME in the "old days" and is continuing today with Google's Dalvik Java VM and now Palm's WebOS WebKit thing. They promise the power and openness of Linux and then shut the door. It's too bad, since a lot of these handhelds have 3D graphic acceleration in their SOCs, and you really need to go native to build a good 3D game or what have you.
I can't wait to see what the Pre SDK looks like, and whether developers buy into this architecture of GUIs based on web technology. And it'll be interesting to see how good the apps can be with it. But if they're as good as the prerelease demos, it's something to pay attention to.
My understanding, and I hope it isn't coming from sources who are also using the same technique to guess at the architecture of this thing, is that the UI for the Palm is rendered totally using WebKit. It appears that the applications for this device are written in JavaScript and use HTML and maybe WebKit's SVG support to render the graphics. Hell, maybe it's even using Dojo to make things look really sharp.
If this is true, then it's going to be a great test of how well this architecture works. I have my worries about how JavaScript scales and how easy it is to write traditional GUI apps, even handheld ones, using HTML as a rendering engine. But looking at the screenshots, it looks pretty awesome.
The other thing I notice is that there is a continuing trend of making it very difficult to build native apps that draw on the screen with these things. It started with JavaME in the "old days" and is continuing today with Google's Dalvik Java VM and now Palm's WebOS WebKit thing. They promise the power and openness of Linux and then shut the door. It's too bad, since a lot of these handhelds have 3D graphic acceleration in their SOCs, and you really need to go native to build a good 3D game or what have you.
I can't wait to see what the Pre SDK looks like, and whether developers buy into this architecture of GUIs based on web technology. And it'll be interesting to see how good the apps can be with it. But if they're as good as the prerelease demos, it's something to pay attention to.
Monday, January 05, 2009
Zune 30, Killed by Complexity
I first heard of it early New Years Eve, I guess. Hoards of Microsoft Zunes were committing mass suicide (a gruesome thought but the actual quote from the Slashdot article). Fears rose that some Y2K thing was happening, mind you things like that didn't happen in Y2K, at least not on this scale. Microsoft finally confirmed the issue as such though, a device driver hang on the 366'th day of a leap year. I'd love to see that code...
Well, thanks to the wonders of the internet, here it is! (I imagine this link will fall dead as soon as the Microsoft cronies make the rounds, as they should. It does have a Microsoft copyright). I actually found it through another blog where the guy put together a pretty good analysis of the problem.
The root cause? A brain fart. Either someone was in a hurry, or they couldn't handle the complexity of the algorithm once they started dealing with leap years. People blame testing for not testing all the paths. But, if you don't take the time to test all the paths, or don't have the skills to properly enumerate all the paths, testing isn't going to matter. At any rate, another great software engineering lesson learned for us all, just like the unhandled exception in the Ariane-5 rocket, except this one is recoverable and isn't as expensive (unless the Zune market share dives as a result, which could happen).
I spend a lot of my time these days working on software architectures and trying to come up with the most simple, extensible, and future proof. But none of that matters if you have code like this. And I've seen code like this all through my career. Hell, I've written some of it. But one thing I learned early from one of my great profs back at the U of S, was on code complexity. It is even measurable by counting the number of paths through your code. Complexity bad. Which implies that having more paths than you need is bad. As we see here, it becomes too difficult to test fully.
And that is certainly the case here. Too many 'if's. How do you convert days since 1980 into a time structure? Well in the Zune code (which is actually a common device driver in a number of Windows CE platforms), one of the paths leads to an infinite loop, when days is 366 and IsLeapYear is true. The author of the blog proposes a much simpler algorithm that works correctly but reduces the paths thus eliminating the bad one. I think you can make it even simpler.
One of my mantras is "I hate typing!". Of course it has nothing to do with typing (much). It's about producing simple elegant solutions to simple problems. Yes, Keep it Simple S(favorite ending here). Saves time. Saves money. Saves embarrassment. Saves your job. I'd hate to be the guy who wrote this code...
Well, thanks to the wonders of the internet, here it is! (I imagine this link will fall dead as soon as the Microsoft cronies make the rounds, as they should. It does have a Microsoft copyright). I actually found it through another blog where the guy put together a pretty good analysis of the problem.
The root cause? A brain fart. Either someone was in a hurry, or they couldn't handle the complexity of the algorithm once they started dealing with leap years. People blame testing for not testing all the paths. But, if you don't take the time to test all the paths, or don't have the skills to properly enumerate all the paths, testing isn't going to matter. At any rate, another great software engineering lesson learned for us all, just like the unhandled exception in the Ariane-5 rocket, except this one is recoverable and isn't as expensive (unless the Zune market share dives as a result, which could happen).
I spend a lot of my time these days working on software architectures and trying to come up with the most simple, extensible, and future proof. But none of that matters if you have code like this. And I've seen code like this all through my career. Hell, I've written some of it. But one thing I learned early from one of my great profs back at the U of S, was on code complexity. It is even measurable by counting the number of paths through your code. Complexity bad. Which implies that having more paths than you need is bad. As we see here, it becomes too difficult to test fully.
And that is certainly the case here. Too many 'if's. How do you convert days since 1980 into a time structure? Well in the Zune code (which is actually a common device driver in a number of Windows CE platforms), one of the paths leads to an infinite loop, when days is 366 and IsLeapYear is true. The author of the blog proposes a much simpler algorithm that works correctly but reduces the paths thus eliminating the bad one. I think you can make it even simpler.
One of my mantras is "I hate typing!". Of course it has nothing to do with typing (much). It's about producing simple elegant solutions to simple problems. Yes, Keep it Simple S(favorite ending here). Saves time. Saves money. Saves embarrassment. Saves your job. I'd hate to be the guy who wrote this code...
Subscribe to:
Posts (Atom)