I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.
It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.
Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.
There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.
I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.
I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.
Anyway, back to bug fixing.
Thursday, October 22, 2009
Thursday, October 08, 2009
A Good Leader is a Good Architect
I've been whining (yeah, that's pretty much the word) a lot recently about the state of contributions to the CDT and about the struggles I face even internally to get more time to spend on open source. I've been pretty frustrated and depressed about that and it's showing in my writing.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.
Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.
I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.
So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.
Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.
Monday, October 05, 2009
Android Notes and Ideas for Eclipse
Here's a few notes on things I've been doing with Android. I'm under no delusion that I can actually create an app for Android. My wife wouldn't be too happy if I spend the time it would need. But I am finding that this is a great exercise getting into the mind of a mobile developer and is giving me ideas on how to improve the CDT and the Eclipse platform.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.
But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.
Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.
The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.
Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.
Sunday, October 04, 2009
No where's that open source hat?
One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.
But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.
All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.
But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.
It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.
But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.
As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.
Monday, September 28, 2009
Remember PluginFest?
It's been a while since it was held. The Eclipse PluginFest was a really cool event organized by Ian Skerrett and hosted by the folks at Symbian in London. It was part marketing event and part engineering event intended to show how off the promise of Eclipse as a platform by doing some interoperability testing between the different products, focusing at the time on the embedded/mobile market. For the most part, it was a success, especially for tools up the stack like analysis and modeling tools.
But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.
But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.
The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).
I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?
But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.
But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.
The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).
I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?
Sunday, September 27, 2009
Phone Games To Hurt Console Market?
Just read the NY Times article here that claims Apple is casting a shadow over the console game market. Of the 758 games shown at this week's Tokyo Game Show, 168 were cell phone games. That's a big number. I'm not sure if the premise is true, but it does open your eyes to a change that is underfoot.
And I think that's were my excitement over the mobile software space is coming from. These cell phones, like my personal HTC Dream Android phone, are decent little gaming machines. Now you aren't going to play first person shooters like I was earlier today with Halo 3 ODST, but for casual gamers they're a hit. And we see it today with the iPhone. When someone shows me their iPhone, it's usually to show off a game running on it.
Android has some growing to do to be a good software platform for mobile games. Good games need to get all the horsepower they can out of the phone without draining the battery, i.e. you need to write as much code to run natively as you can. Until Android gets support for OpenGL and other platform libraries needed to make games into their NDK, gaming on Android will be on a slow growth curve. But once it's there, watch out.
The new platform that caught my eye this week was Moblin, and not just because Intel owns Wind River (my employer). There was a big teaser announcement on Moblin, which until now was a netbook OS, being ported to run on Atom-based phones of the future. Taking a deeper look, I was pleased to see that Moblin really is a Linux "standard" distro with all the gaming libs you need, like OpenGL, gstreamer for audio, SDL for IO, that you get on a desktop Linux distro. I can't wait to see Atom in a phone and see how it compares to the iPhone and Android platforms of the day.
As I keep mentioning here in this blog, it's a great time to be a programmer if you get into the mobile space. There's so much innovation there, and so much opportunity to create something new. And being a non-traditional environment, it's a great place for Eclipse based tools to become the defacto standard, especially the CDT with it's flexible toolchain support and all around IDE goodness. There is activity going on in the community to bring that goodness to these platforms and I can't wait to try them out.
And I think that's were my excitement over the mobile software space is coming from. These cell phones, like my personal HTC Dream Android phone, are decent little gaming machines. Now you aren't going to play first person shooters like I was earlier today with Halo 3 ODST, but for casual gamers they're a hit. And we see it today with the iPhone. When someone shows me their iPhone, it's usually to show off a game running on it.
Android has some growing to do to be a good software platform for mobile games. Good games need to get all the horsepower they can out of the phone without draining the battery, i.e. you need to write as much code to run natively as you can. Until Android gets support for OpenGL and other platform libraries needed to make games into their NDK, gaming on Android will be on a slow growth curve. But once it's there, watch out.
The new platform that caught my eye this week was Moblin, and not just because Intel owns Wind River (my employer). There was a big teaser announcement on Moblin, which until now was a netbook OS, being ported to run on Atom-based phones of the future. Taking a deeper look, I was pleased to see that Moblin really is a Linux "standard" distro with all the gaming libs you need, like OpenGL, gstreamer for audio, SDL for IO, that you get on a desktop Linux distro. I can't wait to see Atom in a phone and see how it compares to the iPhone and Android platforms of the day.
As I keep mentioning here in this blog, it's a great time to be a programmer if you get into the mobile space. There's so much innovation there, and so much opportunity to create something new. And being a non-traditional environment, it's a great place for Eclipse based tools to become the defacto standard, especially the CDT with it's flexible toolchain support and all around IDE goodness. There is activity going on in the community to bring that goodness to these platforms and I can't wait to try them out.
Thursday, September 24, 2009
CDT 6.1, We're not done yet!
We had a couple of really good planning sessions so far this September as we put our plans together for the next release of the CDT, CDT 6.1 for Helios. We've been focused on Build and Debug. We'll continue to move the sticks forward for the editor and parser based features, but build and debug still have some major work to do.
On the build side, we're focused on improving the CDT Scanner Discovery mechanism that scans build output to try and figure out the include paths and defines that you are using for your build. That information is fed to CDT's parser to replicate the parse your compiler does. And that gives us pretty good accuracy to enable things like open declaration and content assist. This work will be a big challenge as we have a bit of a rag-tag group of part timers to try and get this problem area for CDT integrators and users fixed up. But it's a great challenge for me as a project lead to see if we can get as much done as we can.
On the debug side, there's some exciting news. As Ken Ryall from Nokia has been blogging lately, they've been working on a new debugger that's much more tightly integrated with the CDT, and they're ready to contribute it. Essentially, it's a replacement for gdb. Now you can argue whether that's a good thing or a bad thing, but I think it's a good opportunity to improve CDT's debug ability. And of course, it'll be able to sit along side our gdb support which continues to be important for a number of vendors.
But part of Nokia's work that has me most excited, is the native Windows debug support. This is an important step towards finally getting a complete Visual C++ integration for the CDT. I have a build integration almost ready to go. All that was left was debug support. While it is still missing support for Visual C++, Nokia's Windows debug API support gets us maybe half of the way there.
The other good thing about Nokia's work is support for gdbserver as the small agent that does the bit twiddling. Those who've done embedded development know about gdbserver as that's how you do remote debugging of targets using gdb. Reusing gdbserver gives Nokia's work a huge leg up for embedded developers working on all platforms that support gdbserver.
So despite being 7 years into our program, there is still work to be done on CDT. The community is still vibrant. We don't have the big vendor contributions like we used to, other than Nokia of course, but there is still a lot of work to be done and individuals and smaller vendors who are interested in helping. So to quote Monty Python, we're not dead yet :).
On the build side, we're focused on improving the CDT Scanner Discovery mechanism that scans build output to try and figure out the include paths and defines that you are using for your build. That information is fed to CDT's parser to replicate the parse your compiler does. And that gives us pretty good accuracy to enable things like open declaration and content assist. This work will be a big challenge as we have a bit of a rag-tag group of part timers to try and get this problem area for CDT integrators and users fixed up. But it's a great challenge for me as a project lead to see if we can get as much done as we can.
On the debug side, there's some exciting news. As Ken Ryall from Nokia has been blogging lately, they've been working on a new debugger that's much more tightly integrated with the CDT, and they're ready to contribute it. Essentially, it's a replacement for gdb. Now you can argue whether that's a good thing or a bad thing, but I think it's a good opportunity to improve CDT's debug ability. And of course, it'll be able to sit along side our gdb support which continues to be important for a number of vendors.
But part of Nokia's work that has me most excited, is the native Windows debug support. This is an important step towards finally getting a complete Visual C++ integration for the CDT. I have a build integration almost ready to go. All that was left was debug support. While it is still missing support for Visual C++, Nokia's Windows debug API support gets us maybe half of the way there.
The other good thing about Nokia's work is support for gdbserver as the small agent that does the bit twiddling. Those who've done embedded development know about gdbserver as that's how you do remote debugging of targets using gdb. Reusing gdbserver gives Nokia's work a huge leg up for embedded developers working on all platforms that support gdbserver.
So despite being 7 years into our program, there is still work to be done on CDT. The community is still vibrant. We don't have the big vendor contributions like we used to, other than Nokia of course, but there is still a lot of work to be done and individuals and smaller vendors who are interested in helping. So to quote Monty Python, we're not dead yet :).
Monday, September 21, 2009
Eclipse Tools for Mobile Needs Some Buzz
I attended my first Sequoyah (Eclipse tools for mobile, except J2ME, but that's another story) meeting today. Why am I? Well I'm getting more and more into mobile app development in my hobby time, at least for Android anyway, and I'm turning that into a personal focus on better support in CDT for mobile application development. We can then make this available for platform vendors who want to better support developers making applications for their platforms.
My plan is to start by building a set of plug-ins that automate at least the build setup for Android JNI development. Debug is another story and maybe someone else can help with that. And we can look at what's needed for other open source mobile platforms down the road as well. And maybe some other vendor will come along and help out.
But, as I dig into what's happening with mobile at Eclipse, I'm a bit surprised, and disappointed, about how little there actually is. Motorola is putting forth a great effort and contributed a significant amount. As with most vendors (almost all) that contribute to Eclipse it is mainly focused on their own commercial needs. But they also don't seem to be getting much help from anyone else. It takes multiple companies to make a platform and it's sad to see that isn't really happening, despite all the marketing buzz surrounding Pulsar.
And I was also saddened to see Craig Setera's blog for help for the Mobile Tools for Java project. MTJ is probably the project hardest hit from vendors coming and going that I've seen. And after the push to get Craig's EclipseME project merged in for the reboot, I was hoping for greater things there.
On the Sequoyah call, I was asked for advice on how we could solve these things. Man, it's tough. You really need a community, and in particular, a vendor community, that has a vested interest in contributing. We had it easy with the CDT. Everyone needed an extensible C/C++ IDE and it made business sense to invest a person or two to help make it happen. I had it pretty easy as a project lead, and I feel for Craig and the Motorola gang as they try to get this thing going.
The only thing I can come up with is a trick I used in the "dark" days of the CDT after my team at IBM were reallocated. "Create the need". Find something that vendors will see the need to invest in. Usually, this is in the form of some platform piece that they know they need and that multiple vendors can work on, and then show that not enough people are working on it so it's going to suck in their product too.
I'm not sure that's going to work here since there seems to be a huge hesitation to make contributions from the vendors who could be contributing. But that was true with the CDT in the early days too. It was the QNX+Rational show for quite a while until Intel and TI broke the ice.
At any rate, I'm posting this as an attempt to help Eric C out. I'd really like to see Sequoyah succeed and for us to have a nice set of platforms and examplary tools for mobile app development at Eclipse. But that won't happen without growing the community and we'd certainly be interested in your thoughts on how we can make that happen.
My plan is to start by building a set of plug-ins that automate at least the build setup for Android JNI development. Debug is another story and maybe someone else can help with that. And we can look at what's needed for other open source mobile platforms down the road as well. And maybe some other vendor will come along and help out.
But, as I dig into what's happening with mobile at Eclipse, I'm a bit surprised, and disappointed, about how little there actually is. Motorola is putting forth a great effort and contributed a significant amount. As with most vendors (almost all) that contribute to Eclipse it is mainly focused on their own commercial needs. But they also don't seem to be getting much help from anyone else. It takes multiple companies to make a platform and it's sad to see that isn't really happening, despite all the marketing buzz surrounding Pulsar.
And I was also saddened to see Craig Setera's blog for help for the Mobile Tools for Java project. MTJ is probably the project hardest hit from vendors coming and going that I've seen. And after the push to get Craig's EclipseME project merged in for the reboot, I was hoping for greater things there.
On the Sequoyah call, I was asked for advice on how we could solve these things. Man, it's tough. You really need a community, and in particular, a vendor community, that has a vested interest in contributing. We had it easy with the CDT. Everyone needed an extensible C/C++ IDE and it made business sense to invest a person or two to help make it happen. I had it pretty easy as a project lead, and I feel for Craig and the Motorola gang as they try to get this thing going.
The only thing I can come up with is a trick I used in the "dark" days of the CDT after my team at IBM were reallocated. "Create the need". Find something that vendors will see the need to invest in. Usually, this is in the form of some platform piece that they know they need and that multiple vendors can work on, and then show that not enough people are working on it so it's going to suck in their product too.
I'm not sure that's going to work here since there seems to be a huge hesitation to make contributions from the vendors who could be contributing. But that was true with the CDT in the early days too. It was the QNX+Rational show for quite a while until Intel and TI broke the ice.
At any rate, I'm posting this as an attempt to help Eric C out. I'd really like to see Sequoyah succeed and for us to have a nice set of platforms and examplary tools for mobile app development at Eclipse. But that won't happen without growing the community and we'd certainly be interested in your thoughts on how we can make that happen.
Friday, September 18, 2009
Apple leading the way in multi-core programming?
One of my pet study areas is programming paradigms, something I've done since my university days looking at SmallTalk (object-orientation) and Ada (safety critical). The next great next battle line is how to take advantage of multi-core machines to do parallel computing without blowing our poor programmer minds. Intel is doing a lot of work in this area and it's really interesting that Apple is doing the same. I'm not sure why, but good on them.
The two technologies that seem to have sprouted from them and are supported in Snow Leopard are OpenCL, the Khronos standard for mixed GPU/CPU computing, and Apple's Grand Central Dispatch, a task parallelism extension to C, C++, and Objective-C with something called Blocks. There is a recent report from Hardmac.com that shows some real significant improvement form these technologies.
I don't know much about either, but this is definitely something I'm adding to my reading list for those nights I can't get to sleep (which if you're following me on twitter you'll notice are happen regularly).
The two technologies that seem to have sprouted from them and are supported in Snow Leopard are OpenCL, the Khronos standard for mixed GPU/CPU computing, and Apple's Grand Central Dispatch, a task parallelism extension to C, C++, and Objective-C with something called Blocks. There is a recent report from Hardmac.com that shows some real significant improvement form these technologies.
I don't know much about either, but this is definitely something I'm adding to my reading list for those nights I can't get to sleep (which if you're following me on twitter you'll notice are happen regularly).
Saturday, September 12, 2009
State of the Doug
I've been tweeting a lot, but tweets tend to be temporal things that disappear after a short time, so I figured I should blog some of those things. Assuming anyone really cares, but that's part of the mystique and something I call the "cricket factor", when you tweet or blog, and no one's listening, and all you hear back are crickets in the night. But anyway, here's what I'm up to lately.
I made quite a splash recently stating my frank opinion on e4. I had lots of good feedback on that and I pissed off a few people. But I met my objective of making people think about it. To summarize, I worry about the stability of the platform and how e4 will impact the hugely understaffed projects up the stack. And I don't like RAP. If you're running web apps, follow the investment in JavaScript engines and put your UI code in the browser. Which also means I don't care much about the e4 UI work either. But as one e4 committer mentioned to me, "it's fun". I'm sure it is.
As cool and interesting my investigation into GWT has been, I barely get a day a week to do open source work and I still have a couple of things I want to do with the CDT, i.e., help clean up the build system, and support JNI debugging. And I want to spend my hobby time on other things. So enough of that. A lot of people get GWT and how it works well with Equinox, so it'll live on without me.
As for my hobby time, I am getting more and more pumped by what's happening in the Android space. So I'm turning back to that and hope to feed my curiosity on game development by making games for Android. Not sure I'll ever get far enough along to get something on the Android Market, but it'll make a good winter activity. And who knows, maybe we'll see Android running natively on Intel chips some day.
So that's where I am. I have way more ideas than time to work on them having a family and all. But I'll continue to blog and tweet things as they come to me, at least as they relate to open source, and maybe that will help others, or maybe it'll just feed the crickets.
I made quite a splash recently stating my frank opinion on e4. I had lots of good feedback on that and I pissed off a few people. But I met my objective of making people think about it. To summarize, I worry about the stability of the platform and how e4 will impact the hugely understaffed projects up the stack. And I don't like RAP. If you're running web apps, follow the investment in JavaScript engines and put your UI code in the browser. Which also means I don't care much about the e4 UI work either. But as one e4 committer mentioned to me, "it's fun". I'm sure it is.
As cool and interesting my investigation into GWT has been, I barely get a day a week to do open source work and I still have a couple of things I want to do with the CDT, i.e., help clean up the build system, and support JNI debugging. And I want to spend my hobby time on other things. So enough of that. A lot of people get GWT and how it works well with Equinox, so it'll live on without me.
As for my hobby time, I am getting more and more pumped by what's happening in the Android space. So I'm turning back to that and hope to feed my curiosity on game development by making games for Android. Not sure I'll ever get far enough along to get something on the Android Market, but it'll make a good winter activity. And who knows, maybe we'll see Android running natively on Intel chips some day.
So that's where I am. I have way more ideas than time to work on them having a family and all. But I'll continue to blog and tweet things as they come to me, at least as they relate to open source, and maybe that will help others, or maybe it'll just feed the crickets.
Thursday, September 10, 2009
Using CDT for Android Native
Android has a native development kit (NDK) which can be used to create JNI native code for Android applications. In this video, I show how I convert an Android project in Eclipse to add the C/C++ nature to it and set it up to build the shared library that gets included in your Android apk file. This gives you all the power of the CDT in combination with the JDT to build Android apps with native code. Except for debug, though, as JNI debug remains the lost holy grail for the CDT...
If you want to look at the code from the demo, you can clone or download from http://github.com/dschaefer/androidDemo.
Link to YouTube
If you want to look at the code from the demo, you can clone or download from http://github.com/dschaefer/androidDemo.
Link to YouTube
Monday, August 31, 2009
Time to break down the Silos between the *DT's?
What started out as a personal need for writing and debugging JNI-based applications, both based on Eclipse and for Android, has turned into something bigger, a lot bigger. The hardest problem we face for what I'm doing is supporting multiple debugger technologies in the same debug session and ensuring a nice seamless experience. Showing both Java and C/C++ stacks merged together and stepping back and forth between them would be the cat's meow.
As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.
Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)
But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.
I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.
What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.
If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.
As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.
Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)
But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.
I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.
What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.
If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.
Sunday, August 30, 2009
Using Git GUI with Eclipse
Here's my next set of screencasts showing how I use git and git gui in particular with my Eclipse projects. There are two parts. The first shows how to set up a workspace based on a git clone repository, i.e. copying a remote repository to your local machine and setting up an Eclipse workspace for that repository. The second part is how I commit and push my changes to the remote server as I develop code. Hope this is useful.
BTW, This is best viewed by clicking on the YouTube link and watching it full screen in HD mode.
Link to YouTube
Link to YouTube
BTW, This is best viewed by clicking on the YouTube link and watching it full screen in HD mode.
Part 1 - Creating your Workspace
Link to YouTube
Part 2 - Committing and pushing a code change
Link to YouTube
Wednesday, August 26, 2009
The JNI Debug Problem
One thing I noticed the other day was that I'm doing a lot of JNI coding lately. In our Wind River Installer, based on p2 BTW, I have native code for doing a few things like compression and getting at the Windows registry. The CDT has native code for doing advanced process management, and getting at the Windows registry. I've played with Android native development which is all based on JNI. And I was thinking of hooking up the ALSA library to do Audio management with my prototype "Eclipse OS". That's a lot of Java/C coding. And, unfortunately, all without a debug solution :(.
JNI debugging was one of the early goals of the CDT. Unfortunately, it has never really materialized, at least not generically in a way we could incorporate into Eclipse. And given that I see a strong symbiotic relationship between Java and C/C++, I am getting more motivated to tackle this problem and see if we couldn't come up with a solution that we can integrate into the JDT and CDT (or maybe just the CDT).
But the first thing you run into when looking at the code, where do you start? I'd like to be able to step into native methods, hit breakpoints in native code and see up the stack all the way into the Java stack. And really have an integrated debug experience where you don't have to do much of a paradigm shift when going between the two worlds. And given the way the Debug platform is structured, that should be possible.
So there's different ways to slice the cat (not that I slice cats, I like cats). You could add an extension point to be able to plug in native handling into the JDT debugger. I'm not sure what the JDT gang feel of that, or whether they've hopefully thought of that. Another solution would be to build a new Eclipse Java debugger component, but base it on CDT's Debug Services Framework. That may make a more natural solution, but I fear it would be a lot of work and it would take a lot of investment to reach parity with JDT's debug solution.
I'd like to hear what the community thinks. What is the right solution. Hopefully we can come together, find the development resources, and finally reach this Holy Grail for the CDT.
JNI debugging was one of the early goals of the CDT. Unfortunately, it has never really materialized, at least not generically in a way we could incorporate into Eclipse. And given that I see a strong symbiotic relationship between Java and C/C++, I am getting more motivated to tackle this problem and see if we couldn't come up with a solution that we can integrate into the JDT and CDT (or maybe just the CDT).
But the first thing you run into when looking at the code, where do you start? I'd like to be able to step into native methods, hit breakpoints in native code and see up the stack all the way into the Java stack. And really have an integrated debug experience where you don't have to do much of a paradigm shift when going between the two worlds. And given the way the Debug platform is structured, that should be possible.
So there's different ways to slice the cat (not that I slice cats, I like cats). You could add an extension point to be able to plug in native handling into the JDT debugger. I'm not sure what the JDT gang feel of that, or whether they've hopefully thought of that. Another solution would be to build a new Eclipse Java debugger component, but base it on CDT's Debug Services Framework. That may make a more natural solution, but I fear it would be a lot of work and it would take a lot of investment to reach parity with JDT's debug solution.
I'd like to hear what the community thinks. What is the right solution. Hopefully we can come together, find the development resources, and finally reach this Holy Grail for the CDT.
Monday, August 24, 2009
What could an Eclipse OS be?
I got some really positive feedback on my quick little demo of the "Eclipse OS" prototype that I've started building. So I've started to capture ideas on the github wiki for the repository that I created there. Feel free to add your thoughts there, or here. Maybe if there's enough interest we could grow a little community around the idea. If not, that's fine too. I'm really just exploring a role Eclipse technologies could play in a browser based "OS" such as the announced Google Chrome OS.
Here's the link to the wiki and here is what I've started with: http://wiki.github.com/dschaefer/eclipseos
What should the Eclipse OS be? Take one of those new fancy 10" netbooks. Install enough Fedora to xinit the Google Chrome browser with the Flash plugin (necessary in my books for a full web experience) and launch an Equinox standalone server. What local web applications would you need to manage your netbook? Feel free to add to this list.
Here's the link to the wiki and here is what I've started with: http://wiki.github.com/dschaefer/eclipseos
What should the Eclipse OS be? Take one of those new fancy 10" netbooks. Install enough Fedora to xinit the Google Chrome browser with the Flash plugin (necessary in my books for a full web experience) and launch an Equinox standalone server. What local web applications would you need to manage your netbook? Feel free to add to this list.
- Power Off. To shutdown the OS and power down, i.e. run the poweroff command. (Update: this is the first app and is now working).
- Install Manager. To install new web apps into the server using p2. Integrate p2 with yum to install native components that the web apps may need.
- Audio Manager. Similar to ALSA mixer but as a web app. To control the volume of the audio in the least. This could be a good first test of writing native code to help implement the service.
- File Manager. To look at and manipulate the files on the system, maybe even open them in the browser.
- Connectivity Manager. To manage wireless and wired network connections.
- Power Manager. To manage power saving modes.
- Office “Suite”. To prepare documentation and presentations while disconnected, like on long flights.
- E-mail. For those who would like offline access to e-mail.
- An IDE so I can build my web apps locally (thus the connection with my Web IDE (W-IDE) prototype).
Wednesday, August 19, 2009
Screencast Test
After asking around twitter, I had a number of people recommend TechSmith's Jing for doing screencasts. These are the same guys that do the masterful Camtasia which is a more full featured, i.e. expensive, solution. Jing does a good job at capturing my screen and audio. It's limited to 5 minute videos, but give that my main purpose is to share quick ideas with my blog readers, I think that's fine.
So here's my first screencast test. I'm showing the current state of my "Eclipse OS", i.e. Fedora minimal install + X + Chrome Browser + OpenJDK + a standalone Equinox app server. There's not much new here. But I'm really just learning how to use this media. One thing I learned as you'll hear half way through, is that my laptop fan kicks in. Drives me nuts, but anyway. Expect a lot more of these in the upcoming weeks. And hopefully, I'll improve the quality as I go to (like talking louder :).
Update: uploaded to Youtube which gives a much better viewing experience, especially in fullscreen mode.
Update 2: Planet Eclipse seems to filter out the embed object. Click on the title to come to blogger to see the real thing.
So here's my first screencast test. I'm showing the current state of my "Eclipse OS", i.e. Fedora minimal install + X + Chrome Browser + OpenJDK + a standalone Equinox app server. There's not much new here. But I'm really just learning how to use this media. One thing I learned as you'll hear half way through, is that my laptop fan kicks in. Drives me nuts, but anyway. Expect a lot more of these in the upcoming weeks. And hopefully, I'll improve the quality as I go to (like talking louder :).
Update: uploaded to Youtube which gives a much better viewing experience, especially in fullscreen mode.
Update 2: Planet Eclipse seems to filter out the embed object. Click on the title to come to blogger to see the real thing.
Saturday, August 15, 2009
Eclipse OS?
I left a pretty cryptic entry last time. Essentially, I am trying see how easy it is to build a Chrome OS using Fedora as a base. It was pretty easy, and I have the instructions on how to do it. I'm going to put together a series of Jing screencasts (my new favorite screencasting tool), to show you how. That'll take a few days to get together, especially given the beautiful weather we're finally getting here in Ottawa.
But I wanted to show you a screenshot of the final result. Because, not only am I doing a Chrome OS look-a-like thing, I'm also putting Fedora's OpenJDK and an Equinox server application on it to run applications locally. In this case, it's the GWT Greetings app that you get when you create a new GWT project in Eclipse.
As I mentioned when I first heard of Chrome OS that it would be great if we could put Equinox on there to run local apps. Now I have a chance to expand on that idea and see whether it makes sense. Once I get the instructions together you can try it to. Could this be a start of an Eclipse OS?
But I wanted to show you a screenshot of the final result. Because, not only am I doing a Chrome OS look-a-like thing, I'm also putting Fedora's OpenJDK and an Equinox server application on it to run applications locally. In this case, it's the GWT Greetings app that you get when you create a new GWT project in Eclipse.
As I mentioned when I first heard of Chrome OS that it would be great if we could put Equinox on there to run local apps. Now I have a chance to expand on that idea and see whether it makes sense. Once I get the instructions together you can try it to. Could this be a start of an Eclipse OS?
Friday, August 14, 2009
Chrome OS Preview?
I'll be posting more on this later, especially how you can do it yourself. But I've built what could be the upcoming Chrome OS. I did it starting from the Fedora 11 net install and added what I needed, which wasn't much. Here's a teaser screenshot until I can firm up the recipe :)
Monday, August 10, 2009
Web apps make me think MVC
I'm blogging more than I'm coding lately, so I'll try to keep this brief. But I noticed someone mention MVC while I was googling around for practical information on GWT. After I thought about it a while, building a web app is a great example of the Model-View-Controller paradigm.
The model is data you store or derive on the server. You can use GWT's RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT's widgets and invokes the control using GWT's Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.
Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I've mentioned in previous posts, I don't think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You're better off using Android's native widget set in Java to accommodate the form factor. That's what mobile app building is all about. What I need now is an implementation of GWT's RPC mechanism in Java using Android's communication APIs, and really interesting things jump into mind.
What this leads you to is having three View implementations for my web-based IDE, that I'm now calling W-IDE. One in the web browser using full GWT, one in Android using Android's native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.
Now, yes, that's three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24" monitor, it's OK to have all those views and taskbars and such visible all at once. In a browser running in a 10" netbook, not so much, and you'd really like to make it page based to take advantage of the browser's history mechanism. And in a 4" smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.
At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP's server-centric architecture is OK to render in the browser (which if you can't tell yet, I'm not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we'll see. I think we have a lot of time to figure this out.
And, yeah, I guess I failed at keeping this short.
The model is data you store or derive on the server. You can use GWT's RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT's widgets and invokes the control using GWT's Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.
Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I've mentioned in previous posts, I don't think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You're better off using Android's native widget set in Java to accommodate the form factor. That's what mobile app building is all about. What I need now is an implementation of GWT's RPC mechanism in Java using Android's communication APIs, and really interesting things jump into mind.
What this leads you to is having three View implementations for my web-based IDE, that I'm now calling W-IDE. One in the web browser using full GWT, one in Android using Android's native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.
Now, yes, that's three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24" monitor, it's OK to have all those views and taskbars and such visible all at once. In a browser running in a 10" netbook, not so much, and you'd really like to make it page based to take advantage of the browser's history mechanism. And in a 4" smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.
At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP's server-centric architecture is OK to render in the browser (which if you can't tell yet, I'm not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we'll see. I think we have a lot of time to figure this out.
And, yeah, I guess I failed at keeping this short.
Friday, August 07, 2009
Are we de-evolving or on a natural evolution?
Talking around the office about a future with web-based IDEs, it was interesting that people are starting to get it, or at least, not scoff that it's something we'll ever to deal with. There are some good aspects to it for the tools business. At the least it's a great way to quickly get our products out to customers with minimal install fuss (the bane of my existence these days at work), and it's a great way to get immediate feedback on what they find valuable.
The question that needs to be answered is why now? I remember back in the 90's we were clamoring to get away from the client/server model. Everyone wanted a PC or workstation on their desk and former stars of the server world, DEC in particular comes to mind, faded away. Servers found a new life thanks to the web and it seems now, about 20 years later, we starting to climb back onto the client/server bandwagon. Why did we get away from that architecture and what's happening to make us want to go back.
From what I know, looking back, I think one of the biggest problems with servers in the 80's and early 90's was their sheer cost. They were expensive machines. You could buy 100 PCs for the cost of one of these things. Worse, yet, they didn't provide 100 times the compute power. The price/performance ratio made PCs a smart bet. They are both cheep and powerful. That, and they provided freedom to the user. If the server went down, they could keep working, and if they wanted to install some "forbidden" software, they could do it. It was really refreshing come to think of it.
But as any IT professional, or installer guy, would tell you, maintenance of all these machines is a nightmare, for the admin, and for the bottom line. As employees of larger companies well know, there are companies making money on software that beaver away in the background making sure all the other software is kept up-to-date and on the up-and-up. And, of course, some of the more rogue employees know how to uninstall that software and get it out of the way ;).
What the old server model provided was that ease of maintenance. You installed software on one machine and all your users had instant access to it. Of course there are risks to that as all of us tweeters had to deal with today, but with an improved focus on security and robustness with these critical server apps, like we had in the server era, those should become rare.
That, and looking at the cost of servers these days, the costs are way down. I would think that the price/performance curve is turning towards the server side. And just look around your workplace and count the number of CPUs sitting idly. It would be an interesting study to figure out what percentage of CPU power companies have is actually being used. It might make more sense to spend more on servers and less on desktops. You don't need that much power to run a web browser, especially with the ever improving JavaScript VMs that we are finding in them these days.
It's not really far fetched today to see a future, say five years away, where all of our apps are running on servers, in the "cloud" say, and we are accessing them through "dumb" terminals running web browsers, which is what Google's Chrome OS and I'm sure others will provide. The economics are right. The culture though is something else. Are users ready to give up the freedom that traditional desktops provide? I think so, but only if the applications provide significant new value. Tools that integrate with other web apps to allow collaboration over the web could provide that value. Running desktop-style apps that simply display themselves in a web browser, will not.
The question that needs to be answered is why now? I remember back in the 90's we were clamoring to get away from the client/server model. Everyone wanted a PC or workstation on their desk and former stars of the server world, DEC in particular comes to mind, faded away. Servers found a new life thanks to the web and it seems now, about 20 years later, we starting to climb back onto the client/server bandwagon. Why did we get away from that architecture and what's happening to make us want to go back.
From what I know, looking back, I think one of the biggest problems with servers in the 80's and early 90's was their sheer cost. They were expensive machines. You could buy 100 PCs for the cost of one of these things. Worse, yet, they didn't provide 100 times the compute power. The price/performance ratio made PCs a smart bet. They are both cheep and powerful. That, and they provided freedom to the user. If the server went down, they could keep working, and if they wanted to install some "forbidden" software, they could do it. It was really refreshing come to think of it.
But as any IT professional, or installer guy, would tell you, maintenance of all these machines is a nightmare, for the admin, and for the bottom line. As employees of larger companies well know, there are companies making money on software that beaver away in the background making sure all the other software is kept up-to-date and on the up-and-up. And, of course, some of the more rogue employees know how to uninstall that software and get it out of the way ;).
What the old server model provided was that ease of maintenance. You installed software on one machine and all your users had instant access to it. Of course there are risks to that as all of us tweeters had to deal with today, but with an improved focus on security and robustness with these critical server apps, like we had in the server era, those should become rare.
That, and looking at the cost of servers these days, the costs are way down. I would think that the price/performance curve is turning towards the server side. And just look around your workplace and count the number of CPUs sitting idly. It would be an interesting study to figure out what percentage of CPU power companies have is actually being used. It might make more sense to spend more on servers and less on desktops. You don't need that much power to run a web browser, especially with the ever improving JavaScript VMs that we are finding in them these days.
It's not really far fetched today to see a future, say five years away, where all of our apps are running on servers, in the "cloud" say, and we are accessing them through "dumb" terminals running web browsers, which is what Google's Chrome OS and I'm sure others will provide. The economics are right. The culture though is something else. Are users ready to give up the freedom that traditional desktops provide? I think so, but only if the applications provide significant new value. Tools that integrate with other web apps to allow collaboration over the web could provide that value. Running desktop-style apps that simply display themselves in a web browser, will not.
Subscribe to:
Posts (Atom)