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.
Monday, March 17, 2008
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 :)
Thursday, February 28, 2008
Conference season is upon us
I'm having a hard time getting into writing my paper for the upcoming Embedded Systems Conference. So I figured I'd spend some time writing here where I seem to never have writer's block, at least once I find a topic to talk about and a second to do it.
But it's a sign of the time of year. EclipseCon is just over two weeks away and then this year the Embedded Systems Conference and the Eclipse PluginFest for Mobile/Embedded are happening in the same week in April. Time to get prepared.
The PluginFest is a special event that we started last year. It was a pretty interesting time. Part of it was the thrill of spending some time in London, England (which I hear is nicer than London, Ontario, Canada but I've never been to the latter :). But I think it was mainly the chance to get together with Eclipse people again. We have a great community that have some really interesting and passionate individuals that make these events a must attend.
The PluginFest is a bit different than your average Eclipse event, in that you are encouraged to talk about your commercial product and work with other commercial vendors as we prove that the concept of plug-in truly does enable the interoperability between these products that we promise.
And a key component of the interoperability story is the Eclipse platform projects that everyone works to extend. These projects, which include the CDT and DSDP projects, become a bit of a focus as well. I talked to a number of people last year who had questions and ideas for me and the CDT. And I hear there's a keen interested in having project members present again this year.
But that left me a little concerned. EclipseCon is actually a month earlier than the PluginFest this year. And in many ways EclipseCon is meant to be the venue for people working on projects to gather and discuss and ask. For some reason, though, we've always had trouble getting a strong program and attendance from the embedded community for EclipseCon.
It really shows that there is still a lot of work to be done to boost that community. Which is odd, since they are a community that I think desperately needs Eclipse technology to work for them. But then maybe that's one reason why. It doesn't necessarily work for them.
But it's a sign of the time of year. EclipseCon is just over two weeks away and then this year the Embedded Systems Conference and the Eclipse PluginFest for Mobile/Embedded are happening in the same week in April. Time to get prepared.
The PluginFest is a special event that we started last year. It was a pretty interesting time. Part of it was the thrill of spending some time in London, England (which I hear is nicer than London, Ontario, Canada but I've never been to the latter :). But I think it was mainly the chance to get together with Eclipse people again. We have a great community that have some really interesting and passionate individuals that make these events a must attend.
The PluginFest is a bit different than your average Eclipse event, in that you are encouraged to talk about your commercial product and work with other commercial vendors as we prove that the concept of plug-in truly does enable the interoperability between these products that we promise.
And a key component of the interoperability story is the Eclipse platform projects that everyone works to extend. These projects, which include the CDT and DSDP projects, become a bit of a focus as well. I talked to a number of people last year who had questions and ideas for me and the CDT. And I hear there's a keen interested in having project members present again this year.
But that left me a little concerned. EclipseCon is actually a month earlier than the PluginFest this year. And in many ways EclipseCon is meant to be the venue for people working on projects to gather and discuss and ask. For some reason, though, we've always had trouble getting a strong program and attendance from the embedded community for EclipseCon.
It really shows that there is still a lot of work to be done to boost that community. Which is odd, since they are a community that I think desperately needs Eclipse technology to work for them. But then maybe that's one reason why. It doesn't necessarily work for them.
Monday, February 25, 2008
Eclipse Board Election Under Way
It's been a quiet campaign, I guess, at least relative to other elections that are going on right now. Thanks to Ed Merks who we can always expect to stir up the pot :) We did end up have a really healthy debate over the way the Committer reps are elected. One thing we're not short of at Eclipse is passionate contributors and that's good for everyone concerned.
I encourage all the committers to take the time to vote. It's a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you're needs.
I have no idea how I'm going to fare since my campaign budget didn't allow for any polling ;), but I'm glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I'm not sure we'll get CNN to cover the results, but it'll be fun to see how it all unfolds.
I encourage all the committers to take the time to vote. It's a pretty complicated ballot and voting scheme and the choices are pretty hard to make since all the candidates are worthy or representing you. I think the next couple of years are going to be critical for Eclipse as contributing vendors shift their investment. We need to make sure the board does what it can to help ensure the continued success of the projects and of the vendors that contribute to and adopt the works of those projects. So make sure you vote for the person who you think can best represent you're needs.
I have no idea how I'm going to fare since my campaign budget didn't allow for any polling ;), but I'm glad I had the opportunity to share my vision for Eclipse and will continue to work with whoever gets elected to help turn that vision into a reality. I'm not sure we'll get CNN to cover the results, but it'll be fun to see how it all unfolds.
Thursday, February 21, 2008
A Voting Scheme That Promotes Diversity
I was going to leave a comment on Ed Merks blog entry on "One Committer, One Vote?", but I found I filled up the space. That probably means I should do it in my own blog.
For those who haven't read Ed's blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.
But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.
Now, it doesn't shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I'm not sure I have much more of a chance of winning than they do. And that's good for Eclipse all round.
For those who haven't read Ed's blog, he reminds us of the Eclipse voting rule that all committers voting in the board elections get their votes lumped together with others working for the same organization. One organization, one vote. And yeah, if you work at IBM like I did when I learned about this, it leaves you feeling pretty insignificant in these things since you only get such a small fraction of one vote.
But I like this rule. I think it does a great job at promoting diversity. When the Eclipse Foundation was started the board went through a huge effort of making sure that Eclipse was seen as independent from its creator, IBM. To do that, they really needed, and still do need, to ensure as many organizations have a voice on the board as feasible. And this rule helps that by giving people outside IBM more of a chance of winning a board seat.
Now, it doesn't shut out people working for large organizations. The other good thing it does is encourage committers working for those organizations to reach out to the greater Eclipse community and not stay hidden behind the corporate walls. And I look at the IBMers running for the board this year and I can say they do just that. So even with this rule, I'm not sure I have much more of a chance of winning than they do. And that's good for Eclipse all round.
Code like you won't be there tomorrow
One of the things that we deal with on most software projects that continue on for a few years is turnover. People come and go. I'm not sure it's more prevalent with the software industry than others, but it is painful. As managers we spend a lot of effort making sure transition plans are put in place when it happens so that the asset that is the developer's knowledge isn't lost.
Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.
So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.
Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.
So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.
Monday, February 18, 2008
Sun Buys My VirtualBox
One of the issues I have to deal with when building Eclipse-based software is the need to test on a number of different platforms. Yeah, "Write Once, Run Everywhere", whatever. To build a proper IDE and especially the new Installer stuff I'm working on, you need to access the native platform. There's no getting away from it. And with that, you need to deal with all the "special" behaviors that these platforms offer you.
And when you're dealing with many platforms, it's gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I've mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I'd try alternatives.
One I found that worked pretty good was VirtualBox built by German company innotek. It's got a weird license. It's "Free for personal use". It has an open source aspect to it but it's a subset of the whole thing that's free for personal use so it's pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.
So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 - innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!
I'm not sure how to interpret Sun's motives or what will happen to VirtualBox once it's in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.
And when you're dealing with many platforms, it's gets pretty expensive and noisy and hot to have all that hardware stacked in your office, so it makes a ton of sense to use software virtualization for test environments. I've mainly used vmware over the years but before going through the hassle of purchasing a new copy for my new job, I thought I'd try alternatives.
One I found that worked pretty good was VirtualBox built by German company innotek. It's got a weird license. It's "Free for personal use". It has an open source aspect to it but it's a subset of the whole thing that's free for personal use so it's pretty confusing. But it performs really well, leveraging the virtualization hardware in new Intel and AMD CPUs. And has guest drivers that make the integration with the host work better too, just like vmware.
So today, I went to their web site to see if there was an update to the software and I found a link to this announcement: New Feb 12, 2008 - innotek to be acquired by Sun Microsystems. What?!? I thought this was just a small outfit that was building a nice VM for fun with hopes of making it big one day. Well, I guess they made it big. Congrats to them!
I'm not sure how to interpret Sun's motives or what will happen to VirtualBox once it's in their hands. But just like MySQL, I hope they keep the open/free aspects of it alive and well and invest in it to make it even better.
Monday, February 11, 2008
MinGW gcc 4.3 - not quite dead yet?
As I march into the exciting world of Virtual Instruments and VST and using the CDT build something I think is really cool, I keep running into the question: what toolchain should I be using for Windows development. Without a debugger, what's the point of using the Visual C++ compiler. My gut tells me that it's probably got a better optimizer than the old 3.4 that MinGW has at the moment, and that will be key to building a high performance plug-in for digital audio workstations.
At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?
I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven't really seen much progress. But maybe I'm just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.
So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn't I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I'm going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.
In my mind that would be huge. With gcc 4.3 with it's strong optimizer along with other goodies like OpenMP, we'll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.
At the end of a recent blog entry I whined about the lack of progress with MinGW. On reflection, I really need to stick with my guns. As a lead for an open source project you know the first thing I would do with someone complaining something like that is to ask them where their contribution was. So I turned it around. How can I help MinGW move up to the latest gcc and gdb and get it all working nicely?
I kept hearing that the gcc had listed mingw as a secondary platform for the upcoming gcc 4.3, yet in the changelog and gcc mailing list, I haven't really seen much progress. But maybe I'm just looking in the wrong places. So I set out to see if I can build it and run some tests. Building gcc is not for the meek and requires the exact right build environment. I was actually able to build it with a simple configure and got a C++ hello world to work. Very cool, and a great sign that someone out there in gcc-land is taking mingw seriously.
So searching around for instructions on how to build the gcc libraries (libgcc and libstdc++) as DLLs, I ran across the mingw-users mailing list (duh, why hadn't I singed up for that list before?). It appears that there is progress being made in this area. I was kindly provided with build instructions from the former gcc guru on mingw who appears to be taking a closer look again. So I'm going to try to reproduce the build and help him out. If we can get another couple of guys doing the same thing and providing patches where things are broken, we should be able to get this into release shape.
In my mind that would be huge. With gcc 4.3 with it's strong optimizer along with other goodies like OpenMP, we'll have a great compiler for Windows development and for Wascana. And then I can focus on gdb, which also appears to be making progress at mingw. Things might not be as stark as I had made things out to be, especially if I put some effort in helping out.
Friday, February 08, 2008
You're Running for What?
I guess if you look through the history of this blog, I've complained the odd time about how frustrating it can be to work in the Eclipse environment. Now don't get me wrong, the frustration is incredibly minor compared to they success I've had in helping create a successful C/C++ IDE in the CDT. We've been able to put together a solution that has been very well received by the community and is having good commercial success as well. It's all good, well at least for the most part.
But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I've decided to throw my hat into the ring. It's not an easy decision. I wonder how successful I'll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it'll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.
So what are the kind of things I'm talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I've seen a lot of frustration but I think the solutions are available and don't require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what's going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I'd be interested in finding ways to ensuring that these guidelines are respected.
Of course I have other things that I've mentioned in this blog before. I still am saddened that we can't have complete IDE solutions hosted and branded as Eclipse distributions. I'd love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn't the only solution here.
And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.
I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.
But there are things that I think need to be fixed to make life easier for the committers. With the committer rep Eclipse Board elections coming up, I've decided to throw my hat into the ring. It's not an easy decision. I wonder how successful I'll be at representing the committer community at the board level. And I wonder how the sometimes competing forces between the committer community and the strategic members plays out. But I think it'll be a great personal challenge that will help me grow professionally, and if things work out, will help improve the ability of committers to do their job.
So what are the kind of things I'm talking about? Well, the foremost is the ability for committers to mold Eclipse as a whole into something that their customers can be happy with. There are a lot of interdependencies starting to emerge amongst projects and, of course, we have the big one between everyone and the Eclipse Platform. I've seen a lot of frustration but I think the solutions are available and don't require that we institute anarchy in the projects. Ensuring good inter-project communication channels is the main thing and really requires that projects be diverse and open. All projects need to be as transparent as much as possible so that committers can tell what's going on and can figure out how to influence and contribute in order to get their jobs done. There are guidelines set out by the board for this and I'd be interested in finding ways to ensuring that these guidelines are respected.
Of course I have other things that I've mentioned in this blog before. I still am saddened that we can't have complete IDE solutions hosted and branded as Eclipse distributions. I'd love to find a way to bring GPL/LGPL and other non EPL-licensed code into these solutions in such a way as to minimize the legal risk by adopters and the Foundation itself. I really hope that total prohibition isn't the only solution here.
And, of course, being a committer representative means just that, representing committers. I have a great relationship with the committers on the CDT, DSDP, PTP, Photran projects. These guys have been under-represented at the board level in the past and I hope to rectify that. And at the same time I seek to represent all committers and that means ensuring I have an open door policy to their needs. And I look forward to working with them to get a real sense of the diversity of Eclipse.
I am certainly honored to have the opportunity to participate in this election. As I said being a board member would be a great challenge that would help me focus my passion for Eclipse in new ways. The election itself will be a challenge as there are 7 other very strong candidates. No matter who ends up winning, you can be assured that the committers will be well represented.
Monday, February 04, 2008
Yearning for a good Windows toolchain
I've really started to get into this software synthesizer thing with VST albeit the older 2.4 version since most digital audio workstations don't support the new one (they could learn a lesson from Eclipse about keeping a community happy with API stability). There is a pretty good community sharing ideas and tips and examples. And it's a pretty low overhead activity that has a better chance of turning into a hobby than some of my other grand schemes. Most free software synths seem to be build by individuals (versus my desire to explore game development - ever see the credits at the end of a game?).
So I've started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I've got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I'm using the CDT, of course, with the Microsoft Visual C++ build integration I'm working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.
At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I've had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That's fine for simple things, but I found myself missing a real debugger integration as I've started to get interested in the more complex data structures I need to deal with.
Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I'd love to see gcc 4.x for MinGW and I'd love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn't a bigger community working on better gnu tools for Windows development.
So I've started with the basic VST headers and threw away their SDK since my ego says I can do better (just kidding :). I've got enough so that I have a synthesizer that produces silence. ZeroMemory() is your friend. I'm using the CDT, of course, with the Microsoft Visual C++ build integration I'm working on. It builds fine once I figured out how to get DLL export files (.def) so that the right symbol gets exported. In a bizarre twist, they look for a function called main with a different signature than the usual C main, which causes a compile error with the MSVC compiler.
At any rate the biggest stumbling block I ran into was the lack of a CDT debug integration for Windows. I've had to resort to sprintf and popping up MessageBox dialogs to see if code gets hit and to show values. That's fine for simple things, but I found myself missing a real debugger integration as I've started to get interested in the more complex data structures I need to deal with.
Maybe working on a Windows debugger would make a good Google SOC project. And any student looking for ideas, feel free to make a proposal. Ideally, with all the talent working on gcc and gdb, I'd love to see gcc 4.x for MinGW and I'd love to see (or maybe I just need to figure out) how gdb can be used to debug gcc created DLLs with MSVC created applications. But I find it really disappointing that there isn't a bigger community working on better gnu tools for Windows development.
Tuesday, January 29, 2008
Nokia gets Qt
Sorry, I had to use this title. No one else seems to have picked up on it. But then maybe most people are like I was until I actually met a couple of developers from Trolltech at Eclipse Summit Europe in October and learned that it's actually pronounced 'Qute', Not Q.T.
At any rate, the big news in the mobile software industry today was Nokia's purchase of Trolltech. It's another piece of news that struck me as potentially game changing. Certainly Nokia has been under the gun with all the hype behind Google's Android platform. I think this is a strong move by Nokia to firm up their story.
Now, I've been a little luke warm to Qt. I've received a number of requests to include it in Wascana. I can't. And it violates one of the policies I have for Wascana. That is the open source version of their library uses the GPL license. That means only GPL applications can use that version of it and I don't want to get into that game. "Free" software is a paradox. You can't have freedom of users to do what they want with it, and freedom of developers to license their software how they see fit at the same time. And, of course, being a developer, I tend to side with the developers on this equation.
At the same time, though, I really like the architecture and look of Qt. And I understand Trolltech's need to make money and fund development of Qt. (Remember, I side with the developer). And they do have a pretty good Eclipse/CDT integration for Qt. And the commercial licenses aren't that much of a barrier if you're already used to paying for the libraries you use.
But I always secretly hoped that circumstances would change and we could use Qt without worrying about licensing. Does the transaction with Nokia lead to that circumstance. Apparently not according to the news release and letters to Trolltech's community. But I really think that if Qt had a free commercial license, like the Eclipse Public License, the whole KDE/Qt versus GTK wars would have ended long ago and we'd have peace and unity on the Linux desktop, and maybe on mobile devices too. At the very least, you would have seen a Qt SWT port.
At any rate, the big news in the mobile software industry today was Nokia's purchase of Trolltech. It's another piece of news that struck me as potentially game changing. Certainly Nokia has been under the gun with all the hype behind Google's Android platform. I think this is a strong move by Nokia to firm up their story.
Now, I've been a little luke warm to Qt. I've received a number of requests to include it in Wascana. I can't. And it violates one of the policies I have for Wascana. That is the open source version of their library uses the GPL license. That means only GPL applications can use that version of it and I don't want to get into that game. "Free" software is a paradox. You can't have freedom of users to do what they want with it, and freedom of developers to license their software how they see fit at the same time. And, of course, being a developer, I tend to side with the developers on this equation.
At the same time, though, I really like the architecture and look of Qt. And I understand Trolltech's need to make money and fund development of Qt. (Remember, I side with the developer). And they do have a pretty good Eclipse/CDT integration for Qt. And the commercial licenses aren't that much of a barrier if you're already used to paying for the libraries you use.
But I always secretly hoped that circumstances would change and we could use Qt without worrying about licensing. Does the transaction with Nokia lead to that circumstance. Apparently not according to the news release and letters to Trolltech's community. But I really think that if Qt had a free commercial license, like the Eclipse Public License, the whole KDE/Qt versus GTK wars would have ended long ago and we'd have peace and unity on the Linux desktop, and maybe on mobile devices too. At the very least, you would have seen a Qt SWT port.
Sunday, January 27, 2008
C Dj Trance
Believe or not I'm a big fan of hard rock music. It started with Iron Maiden, etc. in the 80s and moved to Nirvana, etc. in the 90's and with The Cure all throughout. It's what I call my "angry music". Not that I'm an angry guy, but I just love music that challenges me that way. But these days, no one knows how to play guitar anymore so I need to find my angry music elsewhere.
I have to thank my former colleague Johnny C for introducing me to Trance music. Electronic music has also always been an side interest of mine, but I'm a guitar hack first (a favorite memory recently is jamming with Eclipse's very own Steve Northover one night). However, I'm a geek firstest, so any chance to involve my passion for music with computers, I'll all over it. And I just love the rhythms and textures of Trance.
So I had this notion that I could make my own Trance music. There's is actually some good low cost digital audio workstation (DAW) software solutions, including a decent one called REAPER, that I've been playing with to see if I want to get into it. The challenge with these solutions is finding the right software synthesizers and effects to make it all sound good. But I was floored by the number of free DAW plug-ins out there. It's quite the huge underground ecosystem.
The main facilitator of this seems to be a free SDK put out by Steinberg called Virtual Studio Technology or VST. (BTW, there's a Microsoft equivalent called DXi, of course). It was build for their own DAW solution, but they openned up the licensing to allow anyone to take advantage of it, like REAPER. I'm not sure if that makes business sense, but it is helping me get interested in digital music so I may become a customer one day.
I checked out the SDK and even got the sample plug-in to compile using Wascana. Unfortunately, they've released a new version of the SDK that isn't backwards compatible so I couldn't try the plug-in in REAPER which doesn't support it yet. But I was able to launch the plug-in in the test host that comes with the SDK. Everything seemed to work except for the bitmap resources since I don't think we have the gnu resource compiler hooked up in our managed build integration. And unfortunately I ran into trouble getting it to debug at all under gdb. Yet another reason to get the Microsoft debug APIs integrated I guess.
But it does look like the CDT would be a nice IDE for applications like this. With the kind of processor power and multimedia assembly instructions you need to make these audio plug-ins work well in large setups, this is another area where I don't see C++ going away. The experience on Windows could be improved with a nicer Microsoft compiler and debugger integration. And it's a cool way to mix my passion for software with my passion for sound in one place.
I have to thank my former colleague Johnny C for introducing me to Trance music. Electronic music has also always been an side interest of mine, but I'm a guitar hack first (a favorite memory recently is jamming with Eclipse's very own Steve Northover one night). However, I'm a geek firstest, so any chance to involve my passion for music with computers, I'll all over it. And I just love the rhythms and textures of Trance.
So I had this notion that I could make my own Trance music. There's is actually some good low cost digital audio workstation (DAW) software solutions, including a decent one called REAPER, that I've been playing with to see if I want to get into it. The challenge with these solutions is finding the right software synthesizers and effects to make it all sound good. But I was floored by the number of free DAW plug-ins out there. It's quite the huge underground ecosystem.
The main facilitator of this seems to be a free SDK put out by Steinberg called Virtual Studio Technology or VST. (BTW, there's a Microsoft equivalent called DXi, of course). It was build for their own DAW solution, but they openned up the licensing to allow anyone to take advantage of it, like REAPER. I'm not sure if that makes business sense, but it is helping me get interested in digital music so I may become a customer one day.
I checked out the SDK and even got the sample plug-in to compile using Wascana. Unfortunately, they've released a new version of the SDK that isn't backwards compatible so I couldn't try the plug-in in REAPER which doesn't support it yet. But I was able to launch the plug-in in the test host that comes with the SDK. Everything seemed to work except for the bitmap resources since I don't think we have the gnu resource compiler hooked up in our managed build integration. And unfortunately I ran into trouble getting it to debug at all under gdb. Yet another reason to get the Microsoft debug APIs integrated I guess.
But it does look like the CDT would be a nice IDE for applications like this. With the kind of processor power and multimedia assembly instructions you need to make these audio plug-ins work well in large setups, this is another area where I don't see C++ going away. The experience on Windows could be improved with a nicer Microsoft compiler and debugger integration. And it's a cool way to mix my passion for software with my passion for sound in one place.
Wednesday, January 23, 2008
24 is the new 20
Well, I'm sitting here typing away looking at my new 24" widescreen monitor. Pidgin running on one side talking to my kind boss who ordered it for me, Internet Exploder on the other with me typing right here, and a monster Eclipse looking at IResource implementations sitting behind them. It's great.
Way back I blogged about my new widescreen laptop and commented on how liberating it was running Eclipse where had no problem seeing the Package/Project Explorer, editors, and Outline View in their full glory. Now at 24" at 1920x1200, it goes to a new level. The only problem is that I have to turn my head now to go between the Outline View and the left edge of the editor. Oh well. I'm sure if I had anything bigger, it might be too big (did I say that?).
And this size of monitor is getting pretty cheep. This is a good one at only $700. The 20" 4:3 monitors we used to druel about were more than that not so long ago. So if you're in the market for a new monitor for working in Eclipse, 24" is highly recommended.
Way back I blogged about my new widescreen laptop and commented on how liberating it was running Eclipse where had no problem seeing the Package/Project Explorer, editors, and Outline View in their full glory. Now at 24" at 1920x1200, it goes to a new level. The only problem is that I have to turn my head now to go between the Outline View and the left edge of the editor. Oh well. I'm sure if I had anything bigger, it might be too big (did I say that?).
And this size of monitor is getting pretty cheep. This is a good one at only $700. The 20" 4:3 monitors we used to druel about were more than that not so long ago. So if you're in the market for a new monitor for working in Eclipse, 24" is highly recommended.
Monday, January 21, 2008
How slow is Java? Not as much as you may think.
I was reading an article on the D programming language (more on that in an upcoming post). At the end of it, the guy claimed it was close in performance to C++. And he used this benchmarking site as evidence. It measures a number of different programming languages on a couple of x86 platforms at performing various algorithms. Most of the algorithms are pretty intense, so it's a good measure of the raw compute power of their runtimes.
Now any such measure is easy to dispute. Did the programmers have sufficient knowledge in the languages to build implementations that would be efficient? They do allow you to play with different weightings for different factors that may be important to you. But the results are interesting non-the-less.
So, a couple of things caught my eye with the default results. First, C++ is faster than C. That I can see if you use C++ inlining a lot which is not always easy to do in C. But it is only slightly faster so I'd call it a draw.
Second, if you preallocate 64MB of heap (-Xms), which we often do, Java is only 1.7 times slower than C++. I think that is a very important result. We often wondered if the CDT's parsers were slow because they were written in Java. The IBM J9 guys said that was crazy talk and these numbers somewhat show their point. Well written Java that really benefits from JIT should be less than 2 times slower than C++. We were looking for a 10 times performance improvement and would probably have been disappointed if we had rewritten everything in C++ (and I mean disappointed in the career limiting aspects of that decision ;).
I don't know whether to fully trust the numbers on this site, but it does reaffirm my belief that Java isn't that much slower than C++. I still don't like Java, though. Show me something as powerful as the Standard Template Library in Java and I might change my mind. Or the 'foreach' from D...
Now any such measure is easy to dispute. Did the programmers have sufficient knowledge in the languages to build implementations that would be efficient? They do allow you to play with different weightings for different factors that may be important to you. But the results are interesting non-the-less.
So, a couple of things caught my eye with the default results. First, C++ is faster than C. That I can see if you use C++ inlining a lot which is not always easy to do in C. But it is only slightly faster so I'd call it a draw.
Second, if you preallocate 64MB of heap (-Xms), which we often do, Java is only 1.7 times slower than C++. I think that is a very important result. We often wondered if the CDT's parsers were slow because they were written in Java. The IBM J9 guys said that was crazy talk and these numbers somewhat show their point. Well written Java that really benefits from JIT should be less than 2 times slower than C++. We were looking for a 10 times performance improvement and would probably have been disappointed if we had rewritten everything in C++ (and I mean disappointed in the career limiting aspects of that decision ;).
I don't know whether to fully trust the numbers on this site, but it does reaffirm my belief that Java isn't that much slower than C++. I still don't like Java, though. Show me something as powerful as the Standard Template Library in Java and I might change my mind. Or the 'foreach' from D...
Sunday, January 20, 2008
Hey Buddy, Want a Job?
Now that I'm playing manager, certain things occupy my thoughts more than they used to. One of them will be my ability to hire good Eclipse talent as opportunities open up for me to do so. Knowing who I know in the Eclipse community, there is a lot of good talent out there, just none of them really looking for new opportunities. And I'm not the only one who would be interested, I've talked to two other managers who also work for large vendors in the Eclipse community who are struggling finding Eclipse experts.
Now, I wonder if that's just a facet of the industry I am in, i.e., embedded development. The big issue we face is that most of the developers that work in our companies are C/C++ developers, not Java developers let alone Eclipse developers. Not only that, but there is a distinct bias against Java, especially from the guys who have been through the trenches with customers complaining about size/performance in resource critical devices. So needless to say, if we need tools developers, we can no longer really depend on growing them from inside the ranks like we have in the past.
So I wonder what solutions are available to help us poor souls looking for help. Certainly there are job sites out there where potential candidates can post resumes. But with those, I've found it difficult to weed through the masses looking for the right skills. Everyone seems to know enough Eclipse to put it on their listings, but how many know how to make Eclipse plug-ins.
One interesting idea I came up with this weekend is whether having such a job listing site as a part of eclipse.org would be useful. It could be something similar to Plug-in Central that vendors use to advertise their wares. We do have the helpwanted newsgroup, but I'd like to see one where it's more a two way street. Obviously we would need some sort of optional discretion to allow vendors or candidates to be quiet about their searches. But it could make it easier for Eclipse experts and Eclipse managers to find each other.
Now, I wonder if that's just a facet of the industry I am in, i.e., embedded development. The big issue we face is that most of the developers that work in our companies are C/C++ developers, not Java developers let alone Eclipse developers. Not only that, but there is a distinct bias against Java, especially from the guys who have been through the trenches with customers complaining about size/performance in resource critical devices. So needless to say, if we need tools developers, we can no longer really depend on growing them from inside the ranks like we have in the past.
So I wonder what solutions are available to help us poor souls looking for help. Certainly there are job sites out there where potential candidates can post resumes. But with those, I've found it difficult to weed through the masses looking for the right skills. Everyone seems to know enough Eclipse to put it on their listings, but how many know how to make Eclipse plug-ins.
One interesting idea I came up with this weekend is whether having such a job listing site as a part of eclipse.org would be useful. It could be something similar to Plug-in Central that vendors use to advertise their wares. We do have the helpwanted newsgroup, but I'd like to see one where it's more a two way street. Obviously we would need some sort of optional discretion to allow vendors or candidates to be quiet about their searches. But it could make it easier for Eclipse experts and Eclipse managers to find each other.
Thursday, January 10, 2008
Android for gamers on the go
I haven't posted much here lately. I guess starting a new job that's to be expected. I'm having a great time, though, and am learning more about install and licensing (the team I'm managing at Wind) than I've ever have. And I think there are some opportunities to do some cool things in this critical area that doesn't get much of the spotlight. And of course, I still have a lot of CDT work I want to do for Ganymede.
At any rate, one thing you will fine me post more about is Google Android. I've mentioned in the past my passing interest in game development. I've never had the opportunity to do any, but with my teenage sons at that ripe video gaming age, I can't help but think of the cool software that goes into these games and how much fun my boys have with it.
And being a development tools kind of guy and Eclipse in particular, I can't help but think that Eclipse would make an awesome environment to build games including everything from modeling characters and building levels to writing the code to make it all happen. That's my dream for Eclipse anyway.
Now the reason I love Android, is that I think it would make a great mobile gaming platform. And the Android gang must think so to since the SDK already comes with OpenGL ES support for 3D rendering with both a native library and a Java layer. It will be interesting to see what game developers can come up with and how well actual hardware will work. But it'll be fun to watch. And it would be really cool if they used Eclipse to build it.
In the meantime, I see that a Russian game developer has ported their 2D game to Android already. For a look at the YouTube video and article, check here.
At any rate, one thing you will fine me post more about is Google Android. I've mentioned in the past my passing interest in game development. I've never had the opportunity to do any, but with my teenage sons at that ripe video gaming age, I can't help but think of the cool software that goes into these games and how much fun my boys have with it.
And being a development tools kind of guy and Eclipse in particular, I can't help but think that Eclipse would make an awesome environment to build games including everything from modeling characters and building levels to writing the code to make it all happen. That's my dream for Eclipse anyway.
Now the reason I love Android, is that I think it would make a great mobile gaming platform. And the Android gang must think so to since the SDK already comes with OpenGL ES support for 3D rendering with both a native library and a Java layer. It will be interesting to see what game developers can come up with and how well actual hardware will work. But it'll be fun to watch. And it would be really cool if they used Eclipse to build it.
In the meantime, I see that a Russian game developer has ported their 2D game to Android already. For a look at the YouTube video and article, check here.
Subscribe to:
Posts (Atom)