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.
Monday, May 25, 2009
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
Subscribe to:
Posts (Atom)