I've just been reading articles in Wikipedia on dataflow programming. This programming paradigm captures what I think is the greatest need we face to built the multi-threaded applications of the future. It also explains where a lot of the concepts in UML Actions and Activities come from.
From what I understand most of the dataflow languages are visual languages. The SynthMaker tool that came with my Fruity Loops is like that. The page also lists the hardware description languages, Verilog and VHDL, in this category. I think they've left out SystemC since it fits into that mould as well.
But even if dataflow programming is the big new paradigm, I firmly believe that any new paradigm will only be mainstream if it's familiar to developers. There's been some great programming languages over the years that you would swear are much better than C (Ada comes to mind, Pascal was really good too), but if you look at the most popular languages in use today, C-like languages, and C++, Java, and C# in particular, win by a land slide.
So it comes back to what I was mentioning earlier. SystemC is a great example of a C++ library and run-time that implement a different programming paradigm but let you reuse all the skills you've learned with other C++ applications. And, it's an example of a language that supports dataflow programming which we need for massively multiprocessing applications. It's definitely a source of inspiration.
Hey all. This blog records my thoughts of the day about my life on the Eclipse CDT project. I will occasionally give opinions and news regarding the Eclipse CDT - the project and its ecosystem - and on open source in general. Please feel free to comment on anything I say. I appreciate it when people are honest with me. And, please, please, consider all of these opinions mine, not of my employer.
Monday, July 28, 2008
Wednesday, July 23, 2008
Who's leading anyway?
The LinuxHater linked off to Christopher Blizzard's (from OLPC fame and now at Mozilla) blog on the current state of affairs with the GNOME project. He gives some very eye opening insight into what's happening there and the potential future directions for GNOME, GTK, and friends. It's not pretty, literally.
GNOME is getting big in the mobile space, or at least the number of contributors from that space is starting to dominate the GNOME project. And as we all know in the open source world, the contributors are the leaders and get to make the decisions. What this likely means and what blizzard is afraid of is that the GNOME desktop is not going to get the attention it needs to compete with the modern interfaces it competes with. The commercial interest just isn't there to make it happen like it is with GNOME mobile.
He explicitly spells out Qt and Apple as leaders in making good user experiences and developer friendly APIs. My favorite quote of his: "If in a platform-driven market and a platform-driven world you’re not the #1 or #2 player it’s going to be very difficult to make a dent in the market. (This is especially true if Nokia decides to fix the Qt licensing.)" I agree on both fronts. I can't see how GNOME is going to grow without serious innovation. And I hope that Nokia fixes the Qt licensing (wink, wink, nudge, nudge).
Being CDTDoug and focused on embedded and mobile at Wind River and on the success of CDT for Windows development with Wascana, why do I care so much about the Linux desktop? Well I think it's the missing piece in the open source success story. We have Linux as an overwhelming favorite in the server market and it's growing in great strides in the embedded space. But without success on the desktop, my Mom isn't going to care. Which means Microsoft and Apple and closed source technologies as still seen as the right path to innovation by the general public. And until "I am a Mac" dukes it out with "I am a Linux PC", there will always be doubts on whether open source can compete with the big boys.
GNOME is getting big in the mobile space, or at least the number of contributors from that space is starting to dominate the GNOME project. And as we all know in the open source world, the contributors are the leaders and get to make the decisions. What this likely means and what blizzard is afraid of is that the GNOME desktop is not going to get the attention it needs to compete with the modern interfaces it competes with. The commercial interest just isn't there to make it happen like it is with GNOME mobile.
He explicitly spells out Qt and Apple as leaders in making good user experiences and developer friendly APIs. My favorite quote of his: "If in a platform-driven market and a platform-driven world you’re not the #1 or #2 player it’s going to be very difficult to make a dent in the market. (This is especially true if Nokia decides to fix the Qt licensing.)" I agree on both fronts. I can't see how GNOME is going to grow without serious innovation. And I hope that Nokia fixes the Qt licensing (wink, wink, nudge, nudge).
Being CDTDoug and focused on embedded and mobile at Wind River and on the success of CDT for Windows development with Wascana, why do I care so much about the Linux desktop? Well I think it's the missing piece in the open source success story. We have Linux as an overwhelming favorite in the server market and it's growing in great strides in the embedded space. But without success on the desktop, my Mom isn't going to care. Which means Microsoft and Apple and closed source technologies as still seen as the right path to innovation by the general public. And until "I am a Mac" dukes it out with "I am a Linux PC", there will always be doubts on whether open source can compete with the big boys.
Monday, July 21, 2008
LinuxHater, a touch of tough love
From now on, I defer all my opinions on the quality of the Linux desktop and the open source projects that work on it to this guy, the LinuxHater. I started reading this blog after I ran across this article on the 'Z' via the 'dot' written by a guy from Google. It really hits home what both of them have to say.
The hater shares some really honest opinions using some very colorful language (warning - if you're sensitive to that kind of thing) on everything from how hard it is for his grandmother to get into Linux, to how all the forking and duplication that's going on FOSS community is doing some serious harm to our ability to build up the Linux desktop to compete with Mac and Windows. It's a really funny read. And I have to agree with the Google guy. Given how much the hater knows about what he's writing about, he's really a Linux lover who desperately wants Linux to succeed but is loosing his cool in frustration.
And it's hard to argue with what the guy says. Open source is about freedom, freedom of the developer to build whatever he wants, however he wants it. And if he doesn't like working on a project, he can start his own, and even fork the code. What he can't do, however, is fork the developers. And that's what's killing the Linux desktop. Too much duplication is watering everything down. Everyone's so focused on building the best framework, they're forgetting about the average end user who doesn't care, or have the capacity to care, and just wants something that's easy to use and works.
With Eclipse, we're making conscious efforts to avoid this problem. At almost every project creation review someone asks whether the project is duplicating some other project and, if so, we work hard to get everyone to work together to resolve it. I think it helps that Eclipse is very much commercially driven. We understand the economics of open source development. We have very limited resources to invest, and it's so critical to work as a team with other companies, even if we compete in the marketplace. If we can get over that, why can't Linux desktop projects, who don't even have a financial vested interest in succeeding, do the same?
But there's a lot of politics in open source, especially with projects close to the Free Software Foundation. I'm not sure how we get out of it. Hopefully, those involved can see through the sarcasm and listen to the message. Linux rocks as an operating system, it really needs a desktop to match, and the community needs to unite to provide the sufficient resources to build it.
The hater shares some really honest opinions using some very colorful language (warning - if you're sensitive to that kind of thing) on everything from how hard it is for his grandmother to get into Linux, to how all the forking and duplication that's going on FOSS community is doing some serious harm to our ability to build up the Linux desktop to compete with Mac and Windows. It's a really funny read. And I have to agree with the Google guy. Given how much the hater knows about what he's writing about, he's really a Linux lover who desperately wants Linux to succeed but is loosing his cool in frustration.
And it's hard to argue with what the guy says. Open source is about freedom, freedom of the developer to build whatever he wants, however he wants it. And if he doesn't like working on a project, he can start his own, and even fork the code. What he can't do, however, is fork the developers. And that's what's killing the Linux desktop. Too much duplication is watering everything down. Everyone's so focused on building the best framework, they're forgetting about the average end user who doesn't care, or have the capacity to care, and just wants something that's easy to use and works.
With Eclipse, we're making conscious efforts to avoid this problem. At almost every project creation review someone asks whether the project is duplicating some other project and, if so, we work hard to get everyone to work together to resolve it. I think it helps that Eclipse is very much commercially driven. We understand the economics of open source development. We have very limited resources to invest, and it's so critical to work as a team with other companies, even if we compete in the marketplace. If we can get over that, why can't Linux desktop projects, who don't even have a financial vested interest in succeeding, do the same?
But there's a lot of politics in open source, especially with projects close to the Free Software Foundation. I'm not sure how we get out of it. Hopefully, those involved can see through the sarcasm and listen to the message. Linux rocks as an operating system, it really needs a desktop to match, and the community needs to unite to provide the sufficient resources to build it.
Friday, July 18, 2008
Important safety tip
So when you go to redefine the key sequence in Eclipse to do 'Build All' make sure you're hitting the Ctrl key and not the Shift key. It explained why I couldn't define the CXXFLAGS macro in my Makefile. Instead of Ctrl-X Ctrl-M for build all, I had accidentally defined it as Shift-X Shift-M. Weird (that it let me), Cool (that I could do it), but took me a little while to figure out that's what it was and not something wrong with my keyboard when Shift-X didn't do anything :)
BTW, thanks out to the guys who are contributing to the Emacs key bindings. I'm loving it! All I need to add is this Build key sequence, which Emacs doesn't define either anyway.
BTW, thanks out to the guys who are contributing to the Emacs key bindings. I'm loving it! All I need to add is this Build key sequence, which Emacs doesn't define either anyway.
Thursday, July 17, 2008
Now where's that include file?
Yeah, C++ refactoring is our biggest achievement for CDT 5.0. But here's one I found probably more useful in my day to day use of the CDT (which is getting more and more lately which is awesome).
I have a burning need to learn GTK development. I have a little dialog based app that needs to run on Windows, Linux, and Solaris. I have the Windows version done using MinGW's support for win32 programming (now there is an experience for you). Now I need to implement the same thing in GTK for Linux and Solaris.
So I'm going through the GTK 2.0 tutorial on the GTK web site and the first thing it get's me to type in is:
The first thing the CDT does is throw up a warning marker on the line complaining that the CDT indexer couldn't find that include file. Being suspicious, I did a build and sure enough the header file wasn't found. With all the great work the indexer team is doing I really should trust what it's telling me.
So I fired up the Ubuntu package manager and found out that the GTK devel package is indeed installed. What's up?
Then I remembered one of the new CDT features I stumbled across in my 5.0 testing that we really should tell people about more. I went back to the #include statement and after <gtk, I pressed Alt-/ (I use the emacs key bindings, Ctrl-Space for the rest of you). And sure enough, content assist offered me all the include files and dirs that being with 'gtk', including the one I needed, gtk-2.0.
It's just a little thing, but one of the great examples of the information that the CDT can gather for you to help improve your productivity. And it's time to tell people about it...
I have a burning need to learn GTK development. I have a little dialog based app that needs to run on Windows, Linux, and Solaris. I have the Windows version done using MinGW's support for win32 programming (now there is an experience for you). Now I need to implement the same thing in GTK for Linux and Solaris.
So I'm going through the GTK 2.0 tutorial on the GTK web site and the first thing it get's me to type in is:
#include <gtk/gtk.h>
The first thing the CDT does is throw up a warning marker on the line complaining that the CDT indexer couldn't find that include file. Being suspicious, I did a build and sure enough the header file wasn't found. With all the great work the indexer team is doing I really should trust what it's telling me.
So I fired up the Ubuntu package manager and found out that the GTK devel package is indeed installed. What's up?
Then I remembered one of the new CDT features I stumbled across in my 5.0 testing that we really should tell people about more. I went back to the #include statement and after <gtk, I pressed Alt-/ (I use the emacs key bindings, Ctrl-Space for the rest of you). And sure enough, content assist offered me all the include files and dirs that being with 'gtk', including the one I needed, gtk-2.0.
It's just a little thing, but one of the great examples of the information that the CDT can gather for you to help improve your productivity. And it's time to tell people about it...
Tuesday, July 15, 2008
A tribute to ObjecTime
As I mentioned recently, I've been thinking of how you could program UML-like actions using C++ in a manner similar to SystemC. As I worked through the workflows of how actions could receive data and signals on input pins and send stuff on output pins, and how they all hook up together, I started to get a deja-vu feeling.
It brought back a lot of good memories from my years at ObjecTime. You know, we had a lot of this stuff back in the 90's. Mind you, it was almost totally focused on state machines that communicated with eachother using messages, but it had a lot of the multi-threading, action oriented development that we need for multi-core systems.
It was a fun time back then. We were a company of 150 or so working on something we were all very passionate about. It was one hell of a team. And we had some big customers but not many of them. When Rational bought us we saw it as a good thing that would lead our work to greater exposure and a bigger sales force. It didn't pan out that way, but the team lived on and a lot of them are still working on modeling tools for Rational which is now a division of IBM.
But one area where I think we failed was in adoptability. We had some passionate early adopters as customers but there are only so many of those. You certainly don't want to build a business with only that. And it was hard to get the code centric guy to trust the modeling and code generation tools. Let's face it, when it comes to crunch time, you'd rather be in with the code with age old and trusted tools and the modeling tools easily fall by the wayside.
Anyway, that's why I work on the CDT now. Code rules, at least for now. But as we try to introduce complex programming paradigms to facilitate multi-threaded development, I got to wonder if there isn't another ObjecTime out there. We where years ahead of the industry and we knew it. I had feared that the time would never come, but maybe that's not true after all.
It brought back a lot of good memories from my years at ObjecTime. You know, we had a lot of this stuff back in the 90's. Mind you, it was almost totally focused on state machines that communicated with eachother using messages, but it had a lot of the multi-threading, action oriented development that we need for multi-core systems.
It was a fun time back then. We were a company of 150 or so working on something we were all very passionate about. It was one hell of a team. And we had some big customers but not many of them. When Rational bought us we saw it as a good thing that would lead our work to greater exposure and a bigger sales force. It didn't pan out that way, but the team lived on and a lot of them are still working on modeling tools for Rational which is now a division of IBM.
But one area where I think we failed was in adoptability. We had some passionate early adopters as customers but there are only so many of those. You certainly don't want to build a business with only that. And it was hard to get the code centric guy to trust the modeling and code generation tools. Let's face it, when it comes to crunch time, you'd rather be in with the code with age old and trusted tools and the modeling tools easily fall by the wayside.
Anyway, that's why I work on the CDT now. Code rules, at least for now. But as we try to introduce complex programming paradigms to facilitate multi-threaded development, I got to wonder if there isn't another ObjecTime out there. We where years ahead of the industry and we knew it. I had feared that the time would never come, but maybe that's not true after all.
Monday, July 14, 2008
The word with Mark Shuttleworth
I ran across (with the help of slashdot :) this interview with Mr. Ubuntu, Mark Shuttleworth, and found it very interesting. It's a good insight into how a commercial entity is successfully, or hopefully successful, working with the open source community to make things better. I've complained a lot here about the Linux desktop experience and Mark feels the pain and is trying to do something about it.
A couple of interesting points he brings up. One is on the Gnome/GTK versus KDE/Qt battle that's been going on for years, and for years too long IMHO. And he mentions the point that I think is really underlying the issue and that's licensing. GTK is popular because it's LGPL which allows for software using it to pick their own license. Qt is technically and aesthetically better, but sorry, unless it's commercially friendly in a free form, it's going to lose the battle. And apparently it is losing from what is stated in the article.
And as long as the battle continues and the Linux community spend their limited resources on two desktops, the Linux desktop user community is going to pay the price. Mark discusses why he sees Mac OS X as the biggest winner lately in the desktop wars. It's because of Apple's dedication to providing an innovative user experience. That's going to be hard to achieve with Linux without the community rallying behind fixing it, or a major vendor stepping up and investing in it. It sounds like that's what Mark is going to do with Canonical, but they aren't really a major vendor with big pocket books, at least not at this point.
Anyway, an insightful read. A lot of the discussion should be familiar with the Eclipse contributor community. Working and influencing open source is a difficult task and requires some specialized talents. And apparently that bodes well for those that figure it out.
A couple of interesting points he brings up. One is on the Gnome/GTK versus KDE/Qt battle that's been going on for years, and for years too long IMHO. And he mentions the point that I think is really underlying the issue and that's licensing. GTK is popular because it's LGPL which allows for software using it to pick their own license. Qt is technically and aesthetically better, but sorry, unless it's commercially friendly in a free form, it's going to lose the battle. And apparently it is losing from what is stated in the article.
And as long as the battle continues and the Linux community spend their limited resources on two desktops, the Linux desktop user community is going to pay the price. Mark discusses why he sees Mac OS X as the biggest winner lately in the desktop wars. It's because of Apple's dedication to providing an innovative user experience. That's going to be hard to achieve with Linux without the community rallying behind fixing it, or a major vendor stepping up and investing in it. It sounds like that's what Mark is going to do with Canonical, but they aren't really a major vendor with big pocket books, at least not at this point.
Anyway, an insightful read. A lot of the discussion should be familiar with the Eclipse contributor community. Working and influencing open source is a difficult task and requires some specialized talents. And apparently that bodes well for those that figure it out.
Friday, July 11, 2008
A lesson on SystemC
Here's a quick look at an example of SystemC code, you're traditional NAND gate:
It looks like some of hardware description languages I've seen such as Verilog. It lets you model inputs and outputs and a process here named run that takes the inputs a and b and does a nand to produce the output f. And it's all continuous. The module will change the output value as the input values change.
The crazy thing is that this is C++ code. SystemC is a collection of header files that define the templated classes, such as sc_in, and some macros, such as SC_MODULE, as well as a runtime library that models the continuous nature of electronic signals and calls the process methods, such as run in our example, to execute the behaviors at the right time. Very cool use of C++ IMHO.
Now UML Action Semantics isn't that much different than the behavior and structure modeled here. You have actions that have input pins and output pins and a behavior that runs when all the input pins are ready. All actions run in parallel. It's a discrete event system as opposed to continuous, as software tends to be as opposed to hardware. But I wonder whether we can use C++ in a similar way to program action semantics.
With a runtime that uses the underlying OS threading system supporting multi-core systems to run the actions in parallel as much as possible and the familiarity of C++ and existing C++ tools, like the CDT :), but used to program a paradigm very different than traditional sequential C, it has me intrigued...
SC_MODULE(my_nand) {
sc_in<bool> a, b;
sc_out<bool> f;
void run() {
f = !(a && b);
}
SC_CTOR(my_nand) {
SC_METHOD(run);
sensitive << a << b;
}
};
It looks like some of hardware description languages I've seen such as Verilog. It lets you model inputs and outputs and a process here named run that takes the inputs a and b and does a nand to produce the output f. And it's all continuous. The module will change the output value as the input values change.
The crazy thing is that this is C++ code. SystemC is a collection of header files that define the templated classes, such as sc_in, and some macros, such as SC_MODULE, as well as a runtime library that models the continuous nature of electronic signals and calls the process methods, such as run in our example, to execute the behaviors at the right time. Very cool use of C++ IMHO.
Now UML Action Semantics isn't that much different than the behavior and structure modeled here. You have actions that have input pins and output pins and a behavior that runs when all the input pins are ready. All actions run in parallel. It's a discrete event system as opposed to continuous, as software tends to be as opposed to hardware. But I wonder whether we can use C++ in a similar way to program action semantics.
With a runtime that uses the underlying OS threading system supporting multi-core systems to run the actions in parallel as much as possible and the familiarity of C++ and existing C++ tools, like the CDT :), but used to program a paradigm very different than traditional sequential C, it has me intrigued...
Wednesday, July 09, 2008
All eyes on Larrabee
There's been a bit of talk on the web-o-sphere about a report out of the German tech magazine Hiese.de that claimed that the Larrabee multi-core processor that Intel was working on will contain 32 original (well, second generation, but still 20 years old) Pentium cores. In the end, it appears to be just speculation and Intel was quick to squash the rumors. But the logic behind the speculation seems plausible.
The old Pentiums where 3 million transistors and with the new GPUs coming out with over a billion, you pack a lot of cores onto one of those. And I like the concept. Something old is new again. Simplify and multiply. There are a lot of transistors in modern CPUs just to handle out of order execution and try to do as many things at once at the instruction level. But that's pretty complicated but made it simple for the programmer. We've gotten pretty good at doing the simple things, why not just take a step back and use what we know. But, of course, you still need to software to take advantage of it.
Reading the discussions really opened my eyes a bit more. This 32-core thing really is possible and will happen within the next year or so. Are we ready to build software applications that can do 32 things at once in an organized fashion. Thinking about it a bit over my holidays here, there is some existing technology we can use and it'll be pretty familiar. I'll blog more about it in a couple of days or so, but think C++, generics, SystemC, UML action semantics. Mix them all in a pot and I think we can come up with some "soup for the multicore programmer's soul"...
The old Pentiums where 3 million transistors and with the new GPUs coming out with over a billion, you pack a lot of cores onto one of those. And I like the concept. Something old is new again. Simplify and multiply. There are a lot of transistors in modern CPUs just to handle out of order execution and try to do as many things at once at the instruction level. But that's pretty complicated but made it simple for the programmer. We've gotten pretty good at doing the simple things, why not just take a step back and use what we know. But, of course, you still need to software to take advantage of it.
Reading the discussions really opened my eyes a bit more. This 32-core thing really is possible and will happen within the next year or so. Are we ready to build software applications that can do 32 things at once in an organized fashion. Thinking about it a bit over my holidays here, there is some existing technology we can use and it'll be pretty familiar. I'll blog more about it in a couple of days or so, but think C++, generics, SystemC, UML action semantics. Mix them all in a pot and I think we can come up with some "soup for the multicore programmer's soul"...
Wednesday, July 02, 2008
Are you ready for 1000 cores?
Massively parallel computing is something I've been interested in for a while and have blogged about a few times in the past. This blog entry by an Intel Researcher made me think about it again. He continues to proclaim that the future isn't that far away and we had better start designing our software so that it can run on machines with thousands of cores. He worries that we're aren't ready yet and we need to start getting ready. And he's right.
Being a tools guy, I think this is the next big paradigm that the tooling industry needs to address. Object-oriented programming and design was a godsend when machines started scaling up in the size of memory and storage and our programs began filling that with data. We built a lot of tools to help with that. Programming languages and compilers are obvious examples. But so is the JDT and CDT, with their code analysis to show type hierarchies and help you easily find classes. Not to mention all the object modeling tools for drawing pictures of your classes.
Coming up with the languages and compilers and other tools necessary to deal with thousands of concurrently running threads is our next great challenge. This is why I keep one eye on the Parallel Tools Project at Eclipse. They're already in this world dealing with the thousands of processors that run the super computers they work with. This effort is a research project in itself (quite literally if you notice who participates in this project :).
But as the Intel researcher warns, this stuff is going to hit the mainstream soon. We're starting to see that with OpenMP parallel language extensions supported in almost all recent compiler releases, including gcc. And I'm convinced it's an area where modeling can help since you really need to think of your program in multiple dimensions, which is something modeling is good at.
I think it's a matter of time before we're at the head of a new paradigm. I remember the fun we had when object-oriented programming hit the mainstream. I think this one will be just as fun.
Being a tools guy, I think this is the next big paradigm that the tooling industry needs to address. Object-oriented programming and design was a godsend when machines started scaling up in the size of memory and storage and our programs began filling that with data. We built a lot of tools to help with that. Programming languages and compilers are obvious examples. But so is the JDT and CDT, with their code analysis to show type hierarchies and help you easily find classes. Not to mention all the object modeling tools for drawing pictures of your classes.
Coming up with the languages and compilers and other tools necessary to deal with thousands of concurrently running threads is our next great challenge. This is why I keep one eye on the Parallel Tools Project at Eclipse. They're already in this world dealing with the thousands of processors that run the super computers they work with. This effort is a research project in itself (quite literally if you notice who participates in this project :).
But as the Intel researcher warns, this stuff is going to hit the mainstream soon. We're starting to see that with OpenMP parallel language extensions supported in almost all recent compiler releases, including gcc. And I'm convinced it's an area where modeling can help since you really need to think of your program in multiple dimensions, which is something modeling is good at.
I think it's a matter of time before we're at the head of a new paradigm. I remember the fun we had when object-oriented programming hit the mainstream. I think this one will be just as fun.
Saturday, June 28, 2008
Bye Bill. You will be missed
Reading the news I see that today was Bill Gates last day at Microsoft. Apparently, they held a tearful farewell in Redmond for him. And it really does mark a significant moment in the history of our industry and a time to reflect.
If I had a dime for every time I read someone say that Bill Gates crashed their machine or was someone personally affecting their life in some negative way, I'd be as rich as he is (well, maybe not). But as much as you may hate Microsoft and the methods they've used to drive their vision, you have to take a good look at what Bill Gates and company have done and how they've succeeded.
The biggest thing I learned from watching Microsoft is how important it is that you keep focus on software as a business. You may have the coolest widget or the cleanest framework or the fastest algorithm, but unless you have a business story and good business people around you to help sell it, it won't matter as much as it could.
And Bill Gates knew that. Surround yourself with good business people and you give yourself a chance. I've seen it too many times, great technology that has floundered because the team focused too much on the technology and forget to bring the marketing guys into the team, if they had marketing guys to begin with. And it's frustrating to see.
So on this day, even though I'm trying to build a C/C++ Development environment with the CDT that can beat Microsoft Visual Studio at it's own game, I pay tribute to Bill for all he's accomplished and all he's taught this industry. He doesn't hate you, he's just following his business plan.
If I had a dime for every time I read someone say that Bill Gates crashed their machine or was someone personally affecting their life in some negative way, I'd be as rich as he is (well, maybe not). But as much as you may hate Microsoft and the methods they've used to drive their vision, you have to take a good look at what Bill Gates and company have done and how they've succeeded.
The biggest thing I learned from watching Microsoft is how important it is that you keep focus on software as a business. You may have the coolest widget or the cleanest framework or the fastest algorithm, but unless you have a business story and good business people around you to help sell it, it won't matter as much as it could.
And Bill Gates knew that. Surround yourself with good business people and you give yourself a chance. I've seen it too many times, great technology that has floundered because the team focused too much on the technology and forget to bring the marketing guys into the team, if they had marketing guys to begin with. And it's frustrating to see.
So on this day, even though I'm trying to build a C/C++ Development environment with the CDT that can beat Microsoft Visual Studio at it's own game, I pay tribute to Bill for all he's accomplished and all he's taught this industry. He doesn't hate you, he's just following his business plan.
Wednesday, June 25, 2008
CDT 5.0 for Ganymede, Come get Some
CDT 5.0 is out the door and available at your friendly Ganymede update site. I'm sure the Eclipse servers will be busy the next few days. The Eclipse community is vast and they love trying out the shiny new features that we've worked hard on all year to make.
I'm especially proud this year with CDT 5.0. With my new job at Wind River working on a p2 based installer, I've finally have a real reason to use it to write the JNI code that I need for some of the computation intensive parts of it. BTW, I now have proof that the Java version of an algorithm is much, much more compute intensive than a C version, check out the LZMA SDK from 7-Zip.
I'm really enjoying the experience. When I first imported the LZMA SDK into my C project, the first thing I needed to find out was where the main() function was. Let's try the Open Element dialog (Shift-Ctrl-T), typed in main, and there it was! A couple of Open Declarations (F3) later, and I was able to find the implementation of the decode function I needed to use. Awesome and I didn't even notice the Indexer running to find all this stuff. And everything else looked clean and worked well.
So yeah, the JDT guys are probably laughing since they've had all that stuff working well for a few years now. JDT has always been our bar (along with VisualStudio which I think we reached a while ago). But watch out. We may just make the CDT so good that people will wonder what the hype about Java was all about :)
I'm especially proud this year with CDT 5.0. With my new job at Wind River working on a p2 based installer, I've finally have a real reason to use it to write the JNI code that I need for some of the computation intensive parts of it. BTW, I now have proof that the Java version of an algorithm is much, much more compute intensive than a C version, check out the LZMA SDK from 7-Zip.
I'm really enjoying the experience. When I first imported the LZMA SDK into my C project, the first thing I needed to find out was where the main() function was. Let's try the Open Element dialog (Shift-Ctrl-T), typed in main, and there it was! A couple of Open Declarations (F3) later, and I was able to find the implementation of the decode function I needed to use. Awesome and I didn't even notice the Indexer running to find all this stuff. And everything else looked clean and worked well.
So yeah, the JDT guys are probably laughing since they've had all that stuff working well for a few years now. JDT has always been our bar (along with VisualStudio which I think we reached a while ago). But watch out. We may just make the CDT so good that people will wonder what the hype about Java was all about :)
Tuesday, June 24, 2008
:-O Nokia buys Symbian to EPL it
Wow. In case you missed it, Nokia bought up the rest of Symbian (it was already a major investor there) and have united with a number of Symbian stakeholders to form the Symbian Foundation to which Nokia will be contributing the Symbian OS. And from there, they will be working to provide an open source, EPL licensed, version of it.
Wow. We have CDT committers from both Nokia and Symbian and they are a great bunch. I still haven't figured out whether this is a good thing or not, but it certainly stirs up the pot as far as open source mobile platforms go. I think it also helps secure the future of the Symbian OS as a technology. It's hard to compete against the hype of Google Android and at the very least this will give Symbian some attention.
It'll also be interesting to see what kind of community evolves for it. They've certainly seeded it with companies that have a vested interest in Symbian's success. That'll give them a good start. As we all know in Eclipse-land, it's a lot of work to grow a community. But maybe growth isn't the prime objective here. We'll have to wait and see what the pundits say, but going open seems to be the most popular strategy these days to help ensure sure your platform matters. Mind you that may be the Google-envy speaking ;)
Wow. We have CDT committers from both Nokia and Symbian and they are a great bunch. I still haven't figured out whether this is a good thing or not, but it certainly stirs up the pot as far as open source mobile platforms go. I think it also helps secure the future of the Symbian OS as a technology. It's hard to compete against the hype of Google Android and at the very least this will give Symbian some attention.
It'll also be interesting to see what kind of community evolves for it. They've certainly seeded it with companies that have a vested interest in Symbian's success. That'll give them a good start. As we all know in Eclipse-land, it's a lot of work to grow a community. But maybe growth isn't the prime objective here. We'll have to wait and see what the pundits say, but going open seems to be the most popular strategy these days to help ensure sure your platform matters. Mind you that may be the Google-envy speaking ;)
Tuesday, June 17, 2008
Back on Linux
I don't know why I get the urge to blog about my Linux journey. I'm sure it's not very interesting. But after a few days of working hard trying to set up ClearCase the way I want it so I can generate p2 repositories from our Wind River product release views, I've gotten back to why I was a *nix guy back in the day before Windows became a much better desktop.
I guess when you find a use for cpio, you are clearly destined to be a Linux junky. I've also fallen in love with NFS automounting (shh, don't tell my wife, she'll find that weird). When I can go 'cd /net/yow-dschaefe-linux' and get to my Linux box from anywhere on the WAN, that's pretty cool, not to mention handy. Doing a 'cpio > /net/yow-dschaefe-linux' from a ClearCase view on a Linux machine in California to my box in Ottawa and have fairly decent performance, that's the greatness of Linux file systems in a nutshell.
And using KVM to set up a virtual machine to run the version of ClearCase I need and from there to NFS mount a directory from my real hard drive and then to do a ClearCase view export back to my real machine so I can run the generator at full speed, it just rocks. It's not for the meek and it has taken me more time that I wanted to figure it all out, but Google is your friend and now that it's set up, I'm ready to go.
So, yes, I still think Windows is the better desktop, but for file and compute servers, Linux is clearly the champ. But of course, you all know that already :)
I guess when you find a use for cpio, you are clearly destined to be a Linux junky. I've also fallen in love with NFS automounting (shh, don't tell my wife, she'll find that weird). When I can go 'cd /net/yow-dschaefe-linux' and get to my Linux box from anywhere on the WAN, that's pretty cool, not to mention handy. Doing a 'cpio > /net/yow-dschaefe-linux' from a ClearCase view on a Linux machine in California to my box in Ottawa and have fairly decent performance, that's the greatness of Linux file systems in a nutshell.
And using KVM to set up a virtual machine to run the version of ClearCase I need and from there to NFS mount a directory from my real hard drive and then to do a ClearCase view export back to my real machine so I can run the generator at full speed, it just rocks. It's not for the meek and it has taken me more time that I wanted to figure it all out, but Google is your friend and now that it's set up, I'm ready to go.
So, yes, I still think Windows is the better desktop, but for file and compute servers, Linux is clearly the champ. But of course, you all know that already :)
Friday, June 13, 2008
OSGi for native development?
I hinted at this topic in my last entry and when giving my crazy thought of the day last week. It's another Friday, but judging from the comments to those blogs and my gut, I'm convinced now that an OSGi implementation for native development isn't really that crazy.
Everyone has heard of the Microsoft Component Object Model (COM). Even if you don't chances are you've used it. It's now getting long in the tooth but it was a critical technology that led to the success of the Windows platform starting with Windows 95. It was a great way to build up frameworks with plug-ins and to write components that used the services of other components, e.g. a Visual Basic script that ran inside Excel.
But of course, COM is very specific to the Windows platform mainly because of it's reliance on the Windows registry which provided the directory to find the COM classes and objects you need. It also had some weird tricks with threading models and some wacky things called thunks to help to help performance when we were running Windows 95 on our old i486 machines.
But it's been done and there's lots of things we can learn from that, and from the limitations of some of the others, like CORBA. Using C++ as the core technology is one thing we would need to avoid. Different compilers have different ABIs, like how virtual function tables are laid out. As much as we try to evolve, at the end of the day, C is still the best language for interoperability and almost every language provides a way to call C functions.
There was some discussion in the OSGi community around something called Universal OSGi lead by Peter Kriens who is also involved in Eclipse. If anyone knows the status of that I'd be happy to take a look. It shouldn't be too difficult to start with the OSGi APIs that make sense and start implementing a framework to support it.
Everyone has heard of the Microsoft Component Object Model (COM). Even if you don't chances are you've used it. It's now getting long in the tooth but it was a critical technology that led to the success of the Windows platform starting with Windows 95. It was a great way to build up frameworks with plug-ins and to write components that used the services of other components, e.g. a Visual Basic script that ran inside Excel.
But of course, COM is very specific to the Windows platform mainly because of it's reliance on the Windows registry which provided the directory to find the COM classes and objects you need. It also had some weird tricks with threading models and some wacky things called thunks to help to help performance when we were running Windows 95 on our old i486 machines.
But it's been done and there's lots of things we can learn from that, and from the limitations of some of the others, like CORBA. Using C++ as the core technology is one thing we would need to avoid. Different compilers have different ABIs, like how virtual function tables are laid out. As much as we try to evolve, at the end of the day, C is still the best language for interoperability and almost every language provides a way to call C functions.
There was some discussion in the OSGi community around something called Universal OSGi lead by Peter Kriens who is also involved in Eclipse. If anyone knows the status of that I'd be happy to take a look. It shouldn't be too difficult to start with the OSGi APIs that make sense and start implementing a framework to support it.
Thursday, June 12, 2008
Are you situationally aware?
Part of my trip through geekdom lead me to Microsoft Flight Simulator. I've dreamed of becoming a pilot but never had the resources or eyes to do it for real. FS gave me a chance to play and get some sense of what flying is like, mind you without the inner ear working for you, it's certainly nowhere near the same.
Part of the thrill of FS for us geeks is the ability to add your own plug-ins to implement your own instrument gauges and your own airplanes. The gauge SDK was particularly interesting to me and lead me to ponder whether one could create a reasonable flight navigation system with maps and data, much like is common place with modern GPS systems. I think I had enough info to pull it off, but of course, never got the time to do it.
That investigation did help me cross paths with Garmin. They are the leaders in flight navigation systems for general aviation aircraft. They have some pretty sophisticated software and some pretty solid hardware to make it easy to navigate an aircraft through the airways. And they keep getting better, going from simple textual lcd screens, to two dimensional graphical displays showing maps in 2D. And the displays kept getting bigger and contained more and more information to help a pilot with his situation awareness, a key to survival in the cockpit.
And now, they've added 3D display of the terrain and obstacles and other aircraft in your vicinity. Here's a video of a reporter talking to a Garmin rep. It's like the world coming full circle. Instead of trying to figure out how to make a video game more real, they're trying to make reality more like a video game! The reporter asked the right question, aren't pilots going to be more interested in watching this wicked cool technology than look out the airplane like they're supposed to? I know I would.
Anyway, I hope this is the leading edge of what we'll soon see in embedded devices where it makes sense, i.e., more use of 3D graphics. I think it really helps the user experience be more real. We're seeing it already with Mac and Vista. And with announcements like Nvidia's Tegra and seeing what the Garmin has done with their system, I can see it useful for devices as well.
BTW, speaking of the FS SDK, when I mentioned OSGi for C++ the other day, that SDK came to mind and is a great example of how to build a simple component model with interfaces for providing services into a common framework. There are certainly other examples and makes me think standardizing on one at least similar to OSGi, might really be a good idea. More on that later...
Part of the thrill of FS for us geeks is the ability to add your own plug-ins to implement your own instrument gauges and your own airplanes. The gauge SDK was particularly interesting to me and lead me to ponder whether one could create a reasonable flight navigation system with maps and data, much like is common place with modern GPS systems. I think I had enough info to pull it off, but of course, never got the time to do it.
That investigation did help me cross paths with Garmin. They are the leaders in flight navigation systems for general aviation aircraft. They have some pretty sophisticated software and some pretty solid hardware to make it easy to navigate an aircraft through the airways. And they keep getting better, going from simple textual lcd screens, to two dimensional graphical displays showing maps in 2D. And the displays kept getting bigger and contained more and more information to help a pilot with his situation awareness, a key to survival in the cockpit.
And now, they've added 3D display of the terrain and obstacles and other aircraft in your vicinity. Here's a video of a reporter talking to a Garmin rep. It's like the world coming full circle. Instead of trying to figure out how to make a video game more real, they're trying to make reality more like a video game! The reporter asked the right question, aren't pilots going to be more interested in watching this wicked cool technology than look out the airplane like they're supposed to? I know I would.
Anyway, I hope this is the leading edge of what we'll soon see in embedded devices where it makes sense, i.e., more use of 3D graphics. I think it really helps the user experience be more real. We're seeing it already with Mac and Vista. And with announcements like Nvidia's Tegra and seeing what the Garmin has done with their system, I can see it useful for devices as well.
BTW, speaking of the FS SDK, when I mentioned OSGi for C++ the other day, that SDK came to mind and is a great example of how to build a simple component model with interfaces for providing services into a common framework. There are certainly other examples and makes me think standardizing on one at least similar to OSGi, might really be a good idea. More on that later...
Friday, June 06, 2008
Crazy thought of the day
It's Friday. It's been a pretty busy and long week. Got lots done. Working on lots of Eclipse related projects both internal and external. The Red Wings won the Stanley Cup (although I'm very proud of the Pittsburgh fans for their behavior after their team lost at home, they're real hockey fans). I bought a new car (a little Mazda 3 Sport, love it! but hate car shopping). So I think I'm allowed to think some crazy thoughts once in a while.
This one sprouts from a couple of different triggers. First, the latest Emacs discussion and how it would be nicer if we could integrate Eclipse better in a command-line environment. Second, comes from my interest in GUIs for embedded systems. Flash is one idea and trying to figure out how you'd hook a C/C++ app on a device to a Flash-based UI. Third comes from a bit of OSGi envy in that it would be a huge help to C/C++ developers if we had a component system like it.
So the crazy idea is this. Rewrite Eclipse in C++. Maybe rewrite isn't the right word since I hear there are people out there who actually like Java ;). But start producing C++ components that look a lot like Eclipse. I'd start with SWT which is a layer over top of some C and C++ code anyway. Shouldn't be that hard. You could then look at a C++ implementation of OSGi. Bundles would be easy to make, just use DLL/so's instead of jars (of course, I'm missing the point on other componentization issues that OSGi deals with but I can't be that far off). Then continue to add things as they make sense or people have a need.
I did a quick search, since I'm pretty sure the C++ SWT idea had been thought of before. I found a company, PureNative Software, that has actually done it. Mind you, they are using their proprietary Java to C++ compiler to do it, and I would think that leaves in a lot of the glue that SWT uses to bridge the Java/C++ world. But they do have a compelling story.
So I'm going to try and contact myself in a parallel universe to start working on it. Or maybe it'll just remain a dream. But I'll throw it out there to see whether you think it's such a crazy idea or not.
This one sprouts from a couple of different triggers. First, the latest Emacs discussion and how it would be nicer if we could integrate Eclipse better in a command-line environment. Second, comes from my interest in GUIs for embedded systems. Flash is one idea and trying to figure out how you'd hook a C/C++ app on a device to a Flash-based UI. Third comes from a bit of OSGi envy in that it would be a huge help to C/C++ developers if we had a component system like it.
So the crazy idea is this. Rewrite Eclipse in C++. Maybe rewrite isn't the right word since I hear there are people out there who actually like Java ;). But start producing C++ components that look a lot like Eclipse. I'd start with SWT which is a layer over top of some C and C++ code anyway. Shouldn't be that hard. You could then look at a C++ implementation of OSGi. Bundles would be easy to make, just use DLL/so's instead of jars (of course, I'm missing the point on other componentization issues that OSGi deals with but I can't be that far off). Then continue to add things as they make sense or people have a need.
I did a quick search, since I'm pretty sure the C++ SWT idea had been thought of before. I found a company, PureNative Software, that has actually done it. Mind you, they are using their proprietary Java to C++ compiler to do it, and I would think that leaves in a lot of the glue that SWT uses to bridge the Java/C++ world. But they do have a compelling story.
So I'm going to try and contact myself in a parallel universe to start working on it. Or maybe it'll just remain a dream. But I'll throw it out there to see whether you think it's such a crazy idea or not.
Wednesday, June 04, 2008
Eclipse versus Emacs, a battle unfinished
I was watching a presentation and someone was talking about integrating gdb with Emacs and showed a screenshot of it in action. I was at the back of the room and I had to squint, because when i first saw it, I swore it was Eclipse.
In this day in age of Eclipse having every feature of Emacs, save a good scripting and keystroke record/playback story, why would anyone still be using Emacs?
Well, of course, you'd be foolish to think that everyone using Emacs is just going to drop it and jump on the Eclipse bandwagon. And there are still some major technical hurdles that force you to be sympathetic with them.
And this is the challenge we face, especially in the technical and embedded space where the CDT is most popular. Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it's still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it's no good.
With all the talk about e4 and new architectures for the new world going on, we also really need to take a long look at how we can finally beat Emacs. Yes, I'm CDT Doug, but I still use XEmacs on Windows as my main text editor, even to look at C++ files outside of workspaces. I shouldn't have to, you'd think...
In this day in age of Eclipse having every feature of Emacs, save a good scripting and keystroke record/playback story, why would anyone still be using Emacs?
Well, of course, you'd be foolish to think that everyone using Emacs is just going to drop it and jump on the Eclipse bandwagon. And there are still some major technical hurdles that force you to be sympathetic with them.
And this is the challenge we face, especially in the technical and embedded space where the CDT is most popular. Eclipse is too big, too slow to start, and the UI too complex and unless we start addressing some of this, it's still going to be a fight to get these users to buy into our story. There is a lot of value to the extensibility and integration story we are selling, but if the barrier to get Joe and Jane developer to even start the thing is too high, it's no good.
With all the talk about e4 and new architectures for the new world going on, we also really need to take a long look at how we can finally beat Emacs. Yes, I'm CDT Doug, but I still use XEmacs on Windows as my main text editor, even to look at C++ files outside of workspaces. I shouldn't have to, you'd think...
Can old NeWS be new again?
I'm going to really show my age here. Back when I was doing my Masters degree at the University of Saskatchewan (now there's a Canadian word that's hard to say even for Canadians), I was doing graphical representations of software models. Yes, my modeling roots go back 20 years. Essentially, I was trying to come up with a generalized diagramming model that could represent different modeling languages.
When it came time to do the prototype, I had a choice of windowing systems that ran on our Sun and HP boxes we had in the lab. Of course, we had X Windows, X11R2 if I remember correctly which was much better than X10.
We also had this new system from Sun called the Network extensible Window System. It was wacky but very cool and had a wacky and cool acronym, NeWS. Essentially you programmed the window server using PostScript (of all things) that was extended by Sun to handle windowing and input devices and asynchronous communication back to the client. It was quite bizarre to be writing PostScript code to do UI but it was a good way to separate UI from Core with an efficient protocol you got to create yourself to best suite the application.
Unfortunately, the implementation was very slow and awkward and the co-operative multi-tasking made it impossible to debug endless loops (but it did help me learn the Sun equivalent of Ctrl-Alt-Dlt). I eventually picked X Windows and this wacky new language called C++ and the rest is, well, even more history.
What NeWS reminds me of today is this whole concept of Web 2.0, and Flash/Flex in particular. And not because PostScript and ActionScript have the same suffix, but because the architecture is very familiar. And it made me wonder if we could use it in the same way, as a windowing system. I can't remember how I programmed the C side but if we used a similar API and protocol would it be any good? Now if I can only find some 20 year old documentation to find out.
When it came time to do the prototype, I had a choice of windowing systems that ran on our Sun and HP boxes we had in the lab. Of course, we had X Windows, X11R2 if I remember correctly which was much better than X10.
We also had this new system from Sun called the Network extensible Window System. It was wacky but very cool and had a wacky and cool acronym, NeWS. Essentially you programmed the window server using PostScript (of all things) that was extended by Sun to handle windowing and input devices and asynchronous communication back to the client. It was quite bizarre to be writing PostScript code to do UI but it was a good way to separate UI from Core with an efficient protocol you got to create yourself to best suite the application.
Unfortunately, the implementation was very slow and awkward and the co-operative multi-tasking made it impossible to debug endless loops (but it did help me learn the Sun equivalent of Ctrl-Alt-Dlt). I eventually picked X Windows and this wacky new language called C++ and the rest is, well, even more history.
What NeWS reminds me of today is this whole concept of Web 2.0, and Flash/Flex in particular. And not because PostScript and ActionScript have the same suffix, but because the architecture is very familiar. And it made me wonder if we could use it in the same way, as a windowing system. I can't remember how I programmed the C side but if we used a similar API and protocol would it be any good? Now if I can only find some 20 year old documentation to find out.
Monday, June 02, 2008
NVIDIA enters the mobile space
I'm a fan of NVIDIA. I have their graphics cards in my computers at home and one of them has an NVIDIA chipset-based motherboard. I especially like their drivers both for Windows and Linux (yeah, I don't care if it's closed, it's still free). It all leads to a good user experience and a happy customer.
So when they make a big move, I pay attention. And today they announced their Tegra product line. News release is here. And a good analysis from Tom's Hardware is here.
Now, NVIDIA isn't creating anything new here. They're entering a market that's already dominated by some big players, including Texas Instruments (a CDT contributor), Freescale (another CDT contributor who's actually a committer), and others. And I'm sure these guys are saying "Big deal", been there, done that.
But the reason I find it interesting and potentially game changing is the reputation that NVIDIA brings with it as it joins in the fun. NVIDIA is known for cool products that entice excitement, especially with their video card business (just look at the flashy website they have). And I'm sure they'll bring that with them. Which, at the end of the day, will result in some really cool mobile internet devices, or MIDs as their marketing guys call them, which have some impressive video and gaming applications but with long battery life.
I'm pretty confident the other guys will spruce up their products to match, which in then end means a further invigoration of the mobile computing space. It's a fun time to be in the embedded software business.
So when they make a big move, I pay attention. And today they announced their Tegra product line. News release is here. And a good analysis from Tom's Hardware is here.
Now, NVIDIA isn't creating anything new here. They're entering a market that's already dominated by some big players, including Texas Instruments (a CDT contributor), Freescale (another CDT contributor who's actually a committer), and others. And I'm sure these guys are saying "Big deal", been there, done that.
But the reason I find it interesting and potentially game changing is the reputation that NVIDIA brings with it as it joins in the fun. NVIDIA is known for cool products that entice excitement, especially with their video card business (just look at the flashy website they have). And I'm sure they'll bring that with them. Which, at the end of the day, will result in some really cool mobile internet devices, or MIDs as their marketing guys call them, which have some impressive video and gaming applications but with long battery life.
I'm pretty confident the other guys will spruce up their products to match, which in then end means a further invigoration of the mobile computing space. It's a fun time to be in the embedded software business.
Subscribe to:
Posts (Atom)