So I'm busy working with my team at Wind on some new installer work and I need to set up ClearCase to get access to the bits that go into the install. I have this spanking new machine, Quad-core Intel, 4GB RAM, 750GB drive. I really got it so I can run multiple virtual machines on it for testing. But if I could run ClearCase on it too, then I could use it for install builds too.
But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.
So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.
As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.
So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.
Tuesday, May 06, 2008
Monday, May 05, 2008
MinGW gcc 4.3 lives!
This just in, Aaron LaFramboise has just released an alpha version of gcc 4.3 for MinGW. And, of course, they are looking for testers. I know I will be. You can give it a try to by downloading it off of mingw.org. I've been following the mingw-users mailing list and it's been a great place to discuss issues. It's not too busy but it's been busy enough to be useful.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
Friday, May 02, 2008
Open Screen, Another Game Changer?
I just went through some blogs and the Adobe Open Screen web site to try and understand what's going on. If you haven't heard, Adobe is removing licensing restrictions on it's SWF and FLV/F4V file formats that serve us Flash content and all those crazy videos on YouTube and such. In the past, the license on the specs restricted the reader from creating competing players, which has resulted in some pretty weak open source players that relied on the developers reverse engineering and guessing at what the spec is.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Monday, April 28, 2008
Building Windows apps on Linux?
I had this interesting feature request on the Wascana forum. This user would like to use Wascana on Linux to build applications that run on both Linux and Windows. You know, that's an idea that could fly.
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
Sunday, April 27, 2008
Help! I'm not connected...
I mentioned a couple of weeks ago that I have this idea for a visual programming language with inspiration from UML Action Semantics and the SynthMaker virtual instrument programming environment that came with my Fruity Loops thing.
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
Friday, April 25, 2008
C/C++ Top of the Heap, Sort of
The latest TIOBE Programming Community Index has been released. I don't put a lot of weight into surveys like this, especially if I don't know the methodology behind it. As far as I can tell it's based on the popularity of different programming languages as found on the web. I guess it's an all right measure and it co-incides somewhat with my personal observations.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
Friday, April 18, 2008
Eclipse for Embedded in San Jose
I'm back in the valley and gave a talk on Eclipse for Embedded at the Embedded Systems Conference. Unfortunately it was at 8:30 in the morning today (Friday) when the exhibition, where all the fun happens, is all over. But I had around 40 people there which was good to see. I also did a shop talk session yesterday at 7:15 which had close to the same number. It was good to see that they made the effort to be there, and it was good to see that almost all of them use the CDT in their daily work.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
Friday, April 11, 2008
I love the open source spirit
I came across the web site for the GCC and GNU toolchain developers summit. It's being held here in Ottawa and I am wondering if it might be a good idea to go and get more involved with this community. I do fit into the "enthusiast" category with my work on Wascana and my interest in MinGW. We'll see. I also don't want to take up space that someone more of an enthusiast would like to take.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
Friday, April 04, 2008
MinGW entering it's prime?
I have a monitor on files that get released by the MinGW project and I just got a notice that the alpha release of gcc 4.3 for MinGW has just arrived. This follows quite closely behind a tech preview of gdb 6.8 for MinGW which includes a number of improvements to gdb for native Windows development.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
Sunday, March 30, 2008
Unexpected surprise in my Fruity Loops
As I mentioned previously here, I am starting to get into making my own electronic music. I've played guitar for many years as a hobby (and I'm nowhere near as good as Steve Northover) but wanted something that I could play with on the road (yes, I was creating music on my flight down and back to EclipseCon). That and it gave me a way to mix hobby and work since I could build software synthesizers using the CDT and Wascana.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
Friday, March 28, 2008
Eclipse p2, sweet!
As we hinted at EclipseCon last week, my team has been evaluating p2 as the framework for our new installer technology. We're essentially coming from an InstallShield world where we have these big monolithic setup.exe type things and we are looking to make our installs more flexible and open the door to electronic distribution. It's an exciting vision and we're pumped to be working to make it happen.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
Monday, March 24, 2008
The community gets it
I just read Mike Milinkovich's post and it summarizes really well what Eclipse is all about. I'm going to use it as a reference whenever someone asks. And I'm going to add Cory Doctorow's quote to my list of mantras. "Ideas are cheap. Execution is hard". How true is that!
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
Friday, March 21, 2008
Another EclipseCon in the Books
Well, it's finally over. EclipseCon that is. But I think it also marks a beginning for me. I was able to meet so many people and accomplish so much this week, it was definitely the best EclipseCon for me.
I'm just going to drop a quick note here since I really need to get to sleep to catch the 7 a.m. flight out of SFO to Toronto on my way home to Ottawa. It's my wife's birthday and I need to get home in time for at least part of it.
So here are a few quick notes on my experiences here:
* e4 isn't so scary. What's scary is that I appear to have volunteered to drive the flexible resource model in the platform. It's a huge responsibility but it needs to get done and I look forward to keeping the momentum going to make sure we get the right solution in place for everyone who uses platform resources (which is quite a few people I hear!). And a big thank you to McQ and Szymon from the Platform Core team for helping us get this going.
* Embedded at EclipseCon is alive and well. I first ran into this at Eclipse Summit Europe where I met a lot of CDT adopters from the embedded space. I thought it was just a European phenomena. Apparently not. I met even more this week here. This is another thing we need to keep the momentum going.
* We need a grassroots embedded development IDE just like we have with Wascana. From the DSDP BOF there appears to be interest in this. And you can count me in with helping it out. And even more reason to figure out how to ship GPL code from eclipse.org since so much of the common embedded tool chain is GPL.
* Speaking of Wascana, the Microsoft announcement was very underwhelming. I need help interfacing the CDT to the Windows debug APIs. Microsoft, come help me!
* Not only did I learn about it, I learned how to spell Mylyn (sorry again Mik!)
* p2 is the future. Well, it's actually the present and it's great to see it coming together quickly. Given my new role at Wind River, expect to see Wind River participating and contributing.
* I'm getting old. I was in bed before midnight both Monday and Tuesday. Wednesday not so much, but I did feel good when I did. Having said that, I did consume a lot of beer this week, all in the name of community building :)
Well, I'll have more to say later.
I'm just going to drop a quick note here since I really need to get to sleep to catch the 7 a.m. flight out of SFO to Toronto on my way home to Ottawa. It's my wife's birthday and I need to get home in time for at least part of it.
So here are a few quick notes on my experiences here:
* e4 isn't so scary. What's scary is that I appear to have volunteered to drive the flexible resource model in the platform. It's a huge responsibility but it needs to get done and I look forward to keeping the momentum going to make sure we get the right solution in place for everyone who uses platform resources (which is quite a few people I hear!). And a big thank you to McQ and Szymon from the Platform Core team for helping us get this going.
* Embedded at EclipseCon is alive and well. I first ran into this at Eclipse Summit Europe where I met a lot of CDT adopters from the embedded space. I thought it was just a European phenomena. Apparently not. I met even more this week here. This is another thing we need to keep the momentum going.
* We need a grassroots embedded development IDE just like we have with Wascana. From the DSDP BOF there appears to be interest in this. And you can count me in with helping it out. And even more reason to figure out how to ship GPL code from eclipse.org since so much of the common embedded tool chain is GPL.
* Speaking of Wascana, the Microsoft announcement was very underwhelming. I need help interfacing the CDT to the Windows debug APIs. Microsoft, come help me!
* Not only did I learn about it, I learned how to spell Mylyn (sorry again Mik!)
* p2 is the future. Well, it's actually the present and it's great to see it coming together quickly. Given my new role at Wind River, expect to see Wind River participating and contributing.
* I'm getting old. I was in bed before midnight both Monday and Tuesday. Wednesday not so much, but I did feel good when I did. Having said that, I did consume a lot of beer this week, all in the name of community building :)
Well, I'll have more to say later.
Tuesday, March 18, 2008
Mylin & CDT destiny
It's an interesting phenomena at Eclipse how bug reports get to be famous. It's how issues are raised, where discussions on solutions take place, and patches get attached. There are famous bugs in Eclipse that I've heard about and finally, I think we've got one on the go for the CDT. It's bug 162558, the Mylin bridge to the CDT.
I've heard great things about Mylin for a long time. An old colleague of mine raved about it. I tried it and it has a great Eclipse interface to a number of different bug systems. But today, I learned from Mik's talk about the task management features that Mylin provides and how it cleans up the UI to help you focus on what you are working on. It's a different way of working, but I can see that once you adopt it, it'll give developers a huge boost in productivity especially when they are working on multiple things at a time.
We've had bug 162558 around for a long time which asks for CDT support in Mylin's task management system. I think there was concern that it would be a lot of work and CDT developers have always had other things to work on. But Mik promised on the report that it would only take 2-4 weeks. And now we have Jeff Johnston from Red Hat who has signed up to help and has a new plug-in ready to show.
I really think that this is a hugely important development for the CDT. In the C/C++ world, our biggest competitor is still emacs/vi and make, i.e., the command line. It's too easy for new CDT users to get frustrated and throw it away and go back. Much more so than Java developers, for example. Ever write java code with command line tools? It's a lot easier with C/C++ where the tools have been optimized to work well on the command line.
We really need to show the value that will pull users through the learning pains of adopting Eclipse (mind you we need to address those too) and tools such as Mylin can do that. You won't find a command line version of Mylin. So we'll work hard to get the CDT Mylin bridge into CDT 5.0 for Ganymede. It'll be a fun thing to add to my CDT demos and hopefully can convince more people to use the CDT.
I've heard great things about Mylin for a long time. An old colleague of mine raved about it. I tried it and it has a great Eclipse interface to a number of different bug systems. But today, I learned from Mik's talk about the task management features that Mylin provides and how it cleans up the UI to help you focus on what you are working on. It's a different way of working, but I can see that once you adopt it, it'll give developers a huge boost in productivity especially when they are working on multiple things at a time.
We've had bug 162558 around for a long time which asks for CDT support in Mylin's task management system. I think there was concern that it would be a lot of work and CDT developers have always had other things to work on. But Mik promised on the report that it would only take 2-4 weeks. And now we have Jeff Johnston from Red Hat who has signed up to help and has a new plug-in ready to show.
I really think that this is a hugely important development for the CDT. In the C/C++ world, our biggest competitor is still emacs/vi and make, i.e., the command line. It's too easy for new CDT users to get frustrated and throw it away and go back. Much more so than Java developers, for example. Ever write java code with command line tools? It's a lot easier with C/C++ where the tools have been optimized to work well on the command line.
We really need to show the value that will pull users through the learning pains of adopting Eclipse (mind you we need to address those too) and tools such as Mylin can do that. You won't find a command line version of Mylin. So we'll work hard to get the CDT Mylin bridge into CDT 5.0 for Ganymede. It'll be a fun thing to add to my CDT demos and hopefully can convince more people to use the CDT.
Monday, March 17, 2008
EclipseCon is about people
I finally headed up to my hotel room to finish going through the CDT Build tutorial. I think I'm ready, wish me luck.
I was having way too much fun meeting people and catching up with the CDT crowd. That's what this event is all about for me. There's lots of talks I want to go to and learn some of the new areas of Eclipse that I haven't been involved in. But I may end up just sitting in the power lounge meeting people, discussing CDT and Eclipse issues, and just enjoying being a part of this great think called Eclipse.
I was having way too much fun meeting people and catching up with the CDT crowd. That's what this event is all about for me. There's lots of talks I want to go to and learn some of the new areas of Eclipse that I haven't been involved in. But I may end up just sitting in the power lounge meeting people, discussing CDT and Eclipse issues, and just enjoying being a part of this great think called Eclipse.
At EclipseCon 2008
Well, I'm finally settled here at EclipseCon. I'm helping give the CDT Build tutorial latter today and haven't had much time to look at the matereal yet. So I'll be doing that the next few hours.
Of course, I made the "mistake" of coming up to the power lounge to find Chris Recoskie and ended up running into quite a few people. That's the great thing about EclipseCon, it's meeting the people you talk to on the mailing lists. It's a lot easier to talk in person and it's always good to put a face with a name.
The flight down was great and, as it seems to always be, you end up meeting other EclipseConers on the flight. I ran into Jeff McAffer in Ottawa then we picked up Eugene Kuleshov and Andrew Overholt in Toronto. We were a merry band of Eclipse committers and it made a usually arduous journey a lot more fun.
I'm really looking forward to the week. I come with two hats on now. Of course there's the CDT where along with the tutorial, I am giving a short talk on CDT 5.0 Ganymede state of the union, as well we have the CDT BOF on Wednesday night where we will get to meet all the CDT gang and learn a bit more about eachother and talk CDT.
My other hat takes me in the direction of the Eclipse p2 project and Eclipse installer technology in general. Jeff gave me a really interesting demo of p2 used in a way I never thought about, i.e. provisioning software on devices. And it doesn't have to be OSGi based as many assume. It gave me some ideas.
And of course, who could miss the e4 discussions as we as an Eclipse community start to plan out the future of the Eclipse platform.
So if you're here, and you see, please stop me and say hi. I'm always interested to hear your take on the past, present, and future of the CDT and Eclipse. And I really do learn a lot from hearing your story.
Of course, I made the "mistake" of coming up to the power lounge to find Chris Recoskie and ended up running into quite a few people. That's the great thing about EclipseCon, it's meeting the people you talk to on the mailing lists. It's a lot easier to talk in person and it's always good to put a face with a name.
The flight down was great and, as it seems to always be, you end up meeting other EclipseConers on the flight. I ran into Jeff McAffer in Ottawa then we picked up Eugene Kuleshov and Andrew Overholt in Toronto. We were a merry band of Eclipse committers and it made a usually arduous journey a lot more fun.
I'm really looking forward to the week. I come with two hats on now. Of course there's the CDT where along with the tutorial, I am giving a short talk on CDT 5.0 Ganymede state of the union, as well we have the CDT BOF on Wednesday night where we will get to meet all the CDT gang and learn a bit more about eachother and talk CDT.
My other hat takes me in the direction of the Eclipse p2 project and Eclipse installer technology in general. Jeff gave me a really interesting demo of p2 used in a way I never thought about, i.e. provisioning software on devices. And it doesn't have to be OSGi based as many assume. It gave me some ideas.
And of course, who could miss the e4 discussions as we as an Eclipse community start to plan out the future of the Eclipse platform.
So if you're here, and you see, please stop me and say hi. I'm always interested to hear your take on the past, present, and future of the CDT and Eclipse. And I really do learn a lot from hearing your story.
Tuesday, March 11, 2008
CPU vs GPU wars
I just finished reading this great interview on Tom's Hardware with Epic Game's CEO Tim Sweeney (of Unreal fame). This is actually the second part of a three part series and I really like his opinions on the state of PC gaming and what the future may hold.
The part that got me interested in writing about it was his conjecture that in the future, as was in the past, graphics rendering is going to be done in software instead of hardware. As GPU (Graphical Processing Units) become more powerful and general purpose, and with CPUs going multi-core, it just makes more sense to leverage that power in a flexible way with software renderers. He figures it'll get to the point that game programmers won't use DirectX or OpenGL, but will bypass it all and write code that runs directly on the hardware.
He then takes it a step further. If CPUs adopt wider vector computation, or GPUs adopt general purpose instructions, we could see the dividing line between the two blur until you can't tell. He predicts GPUs will reach a point where you can run a Linux kernel on them. If that happens, why would you need a CPU?
As it has been of late, the gaming industry is really driving the investment going into PCs architectures. I doubt any of this would be happening in the consumer space at least without it. But this could really change the players. Could nVidia build their own PC architecture without the help of Intel and AMD? Is this why AMD bought ATI? Is this why Intel is investing so much in multi-core architectures? I don't know, but I can't wait to see what unfolds.
The part that got me interested in writing about it was his conjecture that in the future, as was in the past, graphics rendering is going to be done in software instead of hardware. As GPU (Graphical Processing Units) become more powerful and general purpose, and with CPUs going multi-core, it just makes more sense to leverage that power in a flexible way with software renderers. He figures it'll get to the point that game programmers won't use DirectX or OpenGL, but will bypass it all and write code that runs directly on the hardware.
He then takes it a step further. If CPUs adopt wider vector computation, or GPUs adopt general purpose instructions, we could see the dividing line between the two blur until you can't tell. He predicts GPUs will reach a point where you can run a Linux kernel on them. If that happens, why would you need a CPU?
As it has been of late, the gaming industry is really driving the investment going into PCs architectures. I doubt any of this would be happening in the consumer space at least without it. But this could really change the players. Could nVidia build their own PC architecture without the help of Intel and AMD? Is this why AMD bought ATI? Is this why Intel is investing so much in multi-core architectures? I don't know, but I can't wait to see what unfolds.
Friday, March 07, 2008
How to tell a project is really open
So how do you tell whether a project is truly open or not? Well one way I use is to take a look at the developer mailing list for that project. The volume of traffic there is a good judge not only of the activity of the project but how well the developers communicate with the community.
Now it's much better to look at the archives. I remember signing up to the gcc developers list for a few minutes when 20 or so message jumped in and I quickly unsubscribed. gcc is a massively active project that has contributors that love to communicate. Good or bad, it is what it is, an open project.
And I guess there should be some metric you could calculate to measure the openness, something like number of mail messages versus lines of code committed. If that number is low, you have a closed project, if that number is high then it's open. Not sure if that makes the most sense but then, I wonder that about most metrics anyway.
At any rate, I decided to take a look at a number of *-dev mailing list archives at eclipse.org and see how many pages of items there were in the last year. If you get a chance go check out the archive for the cdt-dev mailing list. I'm proud to say there we're 26 pages of items in the last year. We score pretty high. Mind you being a diverse set of contributors, we have to communicate via the list. It's the only way to get the message out to everyone who needs it.
So when I talk about a project being truly open, I mean the daily business of that project is done in the open on a publicly accessible forum. And if you fill up the subscribers mailboxes with good information, even better.
Now it's much better to look at the archives. I remember signing up to the gcc developers list for a few minutes when 20 or so message jumped in and I quickly unsubscribed. gcc is a massively active project that has contributors that love to communicate. Good or bad, it is what it is, an open project.
And I guess there should be some metric you could calculate to measure the openness, something like number of mail messages versus lines of code committed. If that number is low, you have a closed project, if that number is high then it's open. Not sure if that makes the most sense but then, I wonder that about most metrics anyway.
At any rate, I decided to take a look at a number of *-dev mailing list archives at eclipse.org and see how many pages of items there were in the last year. If you get a chance go check out the archive for the cdt-dev mailing list. I'm proud to say there we're 26 pages of items in the last year. We score pretty high. Mind you being a diverse set of contributors, we have to communicate via the list. It's the only way to get the message out to everyone who needs it.
So when I talk about a project being truly open, I mean the daily business of that project is done in the open on a publicly accessible forum. And if you fill up the subscribers mailboxes with good information, even better.
What do you want Eclipse 4.0 to be?
Well, in a very awkward move, the Eclipse Platform project has combined with the Eclipse Rich Ajax Platform (RAP) project to create a new "component" of the Eclipse Platform called "e4". Apparently they have built a prototype of what the "next version of Eclipse" will look like. I'm a big fan of innovation, I just wish that the community was involved even earlier. And despite Chris zx's claim, you involve people by reaching out to them, not just calling meetings and hoping people come.
The timing of this is probably what drove me off the deep end (and I made some pretty snarky comments on the planning council mailing list and I do apologize for that). You see, I have just given up on my attempt to support flexible projects for our CDT users. As a refresher, I was attempting to implement something like the way Visual Studio manages project files by allowing users to add files and directories from anywhere and to exclude others from showing up in the resource tree.
We had a lot of discussion on the cdt-dev list and I think we've concluded that the only possible solution is to modify the Platform to treat this as a first class feature instead of the crazy workarounds we were trying to do. There are quite a few features in the CDT that started out as workarounds for the Platform's failings. It would make much more sense if we did them by fixing the Platform itself.
But then this "e4" thing came. I have no idea what it is technically. But from what I understand it's an Ajax based thing, since the RAP guys are heavily involved in it. When I think of my vision of the next version of the platform, Ajax isn't on my list. Visual Studio feature parity is. That's what a lot of CDT users care about, including paying ones.
I hope that this new "e4" component/project/people are open to everyone's vision of what Eclipse needs to be. At the very least this has opened up the can of worms and we can get this out in the open. Everyone who depends on the Eclipse Platform needs to participate. And that's probably everyone. I'm not sure how it'll work. But it is critical for Eclipse as a whole to ensure that it does work.
The timing of this is probably what drove me off the deep end (and I made some pretty snarky comments on the planning council mailing list and I do apologize for that). You see, I have just given up on my attempt to support flexible projects for our CDT users. As a refresher, I was attempting to implement something like the way Visual Studio manages project files by allowing users to add files and directories from anywhere and to exclude others from showing up in the resource tree.
We had a lot of discussion on the cdt-dev list and I think we've concluded that the only possible solution is to modify the Platform to treat this as a first class feature instead of the crazy workarounds we were trying to do. There are quite a few features in the CDT that started out as workarounds for the Platform's failings. It would make much more sense if we did them by fixing the Platform itself.
But then this "e4" thing came. I have no idea what it is technically. But from what I understand it's an Ajax based thing, since the RAP guys are heavily involved in it. When I think of my vision of the next version of the platform, Ajax isn't on my list. Visual Studio feature parity is. That's what a lot of CDT users care about, including paying ones.
I hope that this new "e4" component/project/people are open to everyone's vision of what Eclipse needs to be. At the very least this has opened up the can of worms and we can get this out in the open. Everyone who depends on the Eclipse Platform needs to participate. And that's probably everyone. I'm not sure how it'll work. But it is critical for Eclipse as a whole to ensure that it does work.
Sunday, March 02, 2008
Understanding the Canadian Accent
I had a great experience on my first business trip when I worked at ObjecTime. I went with some of our customers from Lucent (this was over 10 years ago when Lucent was a new name) to take a course on the Chorus operating system. They were great people and really made me feel part of the team which is the best way to be if you're a supplier. (I wonder where they are now...)
At any rate, one of discussions we got into talking was about different peoples' accents. I mistakenly made the claim that Canadians didn't have an accent. I was quickly proven wrong and I've since had a number of people comment about my accent. What is this Canadian accent anyway and why do we talk funny like that?
What brought this to mind lately is the way Doug Gaff pronounces Wascana (sorry Doug ;). For those who don't know I got the name Wascana on the trip my family and I made back to my birthplace of Regina, Saskatchewan. Regina has a beautiful man-made lake on the provincial legislature grounds called Wascana. Having spent my high school years there, I figured I knew how to pronounce it. But it turns out it's a great showcase of the Canadian accent since a lot of people I know (not just Doug) have a hard time with it.
So the Canadian accent goes like this. We love to pronounce our vowels. Why put them there if your not going to say them? So the pronounciation goes like this: 'Wass' 'can' 'ah'. All the a's have the same pronounciation. It's not 'Wass' 'con' 'a' as I hear a lot of people say. So if you're wondering if someone is from Canada, ask them to pronounce it. Or pronounce 'about'. You know 'ow-t' with an 'ab' on the front.
It's one of the things I like most about my job and my involvement in Eclipse. I get to meet people from around the world and I get to hear the way a lot of people talk. And you learn that to communicate, you need to understand it. And I'll never forget the confused look on the taxi driver's face when I went to the Eclipse PluginFest in London last year and asked to go to 'south' 'wark'. I showed him my hotel reservation for Southwark Street and he said, "Oh, 'suthuk'". eh? (BTW, thanks to Andrew Ferguson from Symbian in London for teaching me the right way to say it :)
At any rate, one of discussions we got into talking was about different peoples' accents. I mistakenly made the claim that Canadians didn't have an accent. I was quickly proven wrong and I've since had a number of people comment about my accent. What is this Canadian accent anyway and why do we talk funny like that?
What brought this to mind lately is the way Doug Gaff pronounces Wascana (sorry Doug ;). For those who don't know I got the name Wascana on the trip my family and I made back to my birthplace of Regina, Saskatchewan. Regina has a beautiful man-made lake on the provincial legislature grounds called Wascana. Having spent my high school years there, I figured I knew how to pronounce it. But it turns out it's a great showcase of the Canadian accent since a lot of people I know (not just Doug) have a hard time with it.
So the Canadian accent goes like this. We love to pronounce our vowels. Why put them there if your not going to say them? So the pronounciation goes like this: 'Wass' 'can' 'ah'. All the a's have the same pronounciation. It's not 'Wass' 'con' 'a' as I hear a lot of people say. So if you're wondering if someone is from Canada, ask them to pronounce it. Or pronounce 'about'. You know 'ow-t' with an 'ab' on the front.
It's one of the things I like most about my job and my involvement in Eclipse. I get to meet people from around the world and I get to hear the way a lot of people talk. And you learn that to communicate, you need to understand it. And I'll never forget the confused look on the taxi driver's face when I went to the Eclipse PluginFest in London last year and asked to go to 'south' 'wark'. I showed him my hotel reservation for Southwark Street and he said, "Oh, 'suthuk'". eh? (BTW, thanks to Andrew Ferguson from Symbian in London for teaching me the right way to say it :)
Subscribe to:
Posts (Atom)