I was watching my son the other day on our XBOX 360 that's tucked nicely in our cabinet under the TV with our DVD player, digital cable box, and receiver. He was playing Halo 3, which looks great on our LCD HDTV, BTW. He'd break out once in a while and go back to the Dashboard and send a text message to a buddy then go back into the game and use the headset connected to his controller to talk about his school day with another buddy he was shooting at. It's incredible how far consoles have come from the old Atari boxes we had when we were kids. Now they're these multi-processing entertainment centers and communication devices that hook our kids up to the rest of the world.
It's also interesting how he's migrated away from our PC over to the XBOX. That could be because our PC is getting old and the 360 is actually a more powerful machine. But, still there are still things you can't do on it. That would probably be solved if it had a web browser built into it. But for some reason, and correct me if I'm wrong on this, there doesn't seem to be a web browser available for the 360. Weird. Too bad this is a closed platform that makes it really hard to get open source software, like the Webkit browser engine, ported to it.
So that got me thinking in the context of Linux. Why isn't there a Linux console? Linux is slowly getting better for the desktop and it's about to break out huge in the mobile space, wouldn't it also work well in a box I can put under my TV and use with a wireless keyboard, or game controller with a headset, or with the controllers we have for Guitar Hero and Rock Band? I don't see why not.
Googling the idea, you see the GP2X WIZ handheld I've blogged about in the past, and the sad story that was Indrema that rose with the hype of Linux in 2000 and crashed with the market realities of 2001. And yeah, Linux probably wasn't ready in 2000. But nothing seems to be happening now.
And I'm sure there are economic roadblocks to making it happen. The companies in this industry are huge and are still selling the boxes for less than it costs to build them. Having an open platform makes it pretty difficult to collect the license fees that subsidize the hardware and platform development costs. You'd need a big player with big friends, similar to one of the Linux handheld alliances, to even think of making this happen.
But if it works for handhelds, why not on the TV. At least there it would have a bigger screen...
Wednesday, September 10, 2008
Tuesday, September 09, 2008
Get out your lambdas - C++0x
I saw a video of a talk by Bjorn Stroustrup, Mr. C++, who people I work with know I call "Barney", affectionately, of course. In the video, he mentioned how badly he wanted to keep the name of the next major version of the C++ standard as C++0x and not have it slip into the next decade. Well, 2008 is almost over so it's going to have to be C++09 if it's to make it. But they are trying hard and making some progress.
And hopefully it does. C++ is due for a good shot in the arm, something to get people excited about. Working every day in Java as I do, and yearning for my C++ days, there are a few features in Java that would be exciting to have in C++. Not many, but there are a few :).
And one of them appears to be ready to be included in the standard, lambda expressions. Now Java doesn't have pure lambda expressions, but the inner class support comes close. And with C++0x support for more general lambda expressions, I think we have a winner on our hands. Here's an example:
This ain't your father's C++. To explain what's happening, we're passing an anonymous function that takes a parameter y, and we pass along with it a closure which passes on some of the context with the function, in this case a reference to x. Later on the calculateWithCallback function does something and then calls our function with a parameter value for y. We then execute and assign the value to our x and return.
Anyway, very cool. Callbacks is a very popular design pattern and we use it all the time when programming Eclipse plug-ins. Being able to do something like this in a concise manner in C++ will be very useful and help bring C++ into a new decade, or whenever they get the standard ratified.
And hopefully it does. C++ is due for a good shot in the arm, something to get people excited about. Working every day in Java as I do, and yearning for my C++ days, there are a few features in Java that would be exciting to have in C++. Not many, but there are a few :).
And one of them appears to be ready to be included in the standard, lambda expressions. Now Java doesn't have pure lambda expressions, but the inner class support comes close. And with C++0x support for more general lambda expressions, I think we have a winner on our hands. Here's an example:
int x;
calculateWithCallback([&x](int y) { x = y; });
This ain't your father's C++. To explain what's happening, we're passing an anonymous function that takes a parameter y, and we pass along with it a closure which passes on some of the context with the function, in this case a reference to x. Later on the calculateWithCallback function does something and then calls our function with a parameter value for y. We then execute and assign the value to our x and return.
Anyway, very cool. Callbacks is a very popular design pattern and we use it all the time when programming Eclipse plug-ins. Being able to do something like this in a concise manner in C++ will be very useful and help bring C++ into a new decade, or whenever they get the standard ratified.
Wednesday, September 03, 2008
exit() is your friend
I was just reading the Google Chrome cartoon book (an interesting way of presenting designs). One of the things they talked about was how having browser tabs in separate process helps with memory consumption because memory gets cleaned up with the process exits. Otherwise, the constant malloc/free cycle ends up with memory fragmentation that is hard to get rid of.
That brought back some memories. In my early work on a code generator, I used the same philosophy. I created a pretty big object model in memory after I parsed the input, but I never implemented any of the destructors and never called delete. Didn't need to. It was a short lived process and the call to exit() at the end freed up all the memory anyway. And it's pretty fast! Lot faster than calling delete for each object I created.
Anyway that worked great. Until another team decided they liked my object model and wanted to use it in the main tool. Unfortunately that tool was a long running process and they had to add in the memory management to survive. So much for exit() is your friend. Worked for me, though.
Of course all the garbage collector languages deal with this for you. Makes me wonder why GC in C++ hasn't become more popular. There are C++ garbage collectors like the one from Hans Boehm. But I guess if you're moving to that paradigm, you might as well use Java.
That brought back some memories. In my early work on a code generator, I used the same philosophy. I created a pretty big object model in memory after I parsed the input, but I never implemented any of the destructors and never called delete. Didn't need to. It was a short lived process and the call to exit() at the end freed up all the memory anyway. And it's pretty fast! Lot faster than calling delete for each object I created.
Anyway that worked great. Until another team decided they liked my object model and wanted to use it in the main tool. Unfortunately that tool was a long running process and they had to add in the memory management to survive. So much for exit() is your friend. Worked for me, though.
Of course all the garbage collector languages deal with this for you. Makes me wonder why GC in C++ hasn't become more popular. There are C++ garbage collectors like the one from Hans Boehm. But I guess if you're moving to that paradigm, you might as well use Java.
Tuesday, September 02, 2008
Coming Live from Google Chrome
Well, it's live and I've downloaded it and am using it to write this blog entry. It's Google Chrome. It's a beta, but from what I've seen in the couple of minutes I've used it, it's delivering as promised. Very fast and smooth, even typing here. Better than Firefox? Seems like it, but maybe it's the chrome blinding me. And given the news volume about it, there's a lot of people speculating about what Google is trying to accomplish with this thing.
At any rate, if it is about making the Web the OS as we've been trying to do for centuries now, what does it mean to C++ application developers? How do they make their applications relevant in this new world? Is it all over? Do we throw away our C++ compilers and pick up a book on PHP?
I strongly believe there will always be a role for a close to the silicon programming language like C++. Whether it's for resource constrained devices like mobile platforms, or whether it's for high performance apps like image processing or simulations, there's still that need.
What may change is how these C++ apps communicate with the user. I can easily imagine a Web-based UI for C++ apps, similar to other Web 2.0 platforms. Who says the server side needs to be Java or PHP? It could easily be a C++ app. What we need, though, is a clean way to program such a UI. C++ widget programming has always been a challenge, but wait until you change the paradigm like this.
This is one reason I'm keeping an eye on the "Webification of SWT" part of the Eclipse e4 project. The lessons learned and the technology choices made there should be portable to a similar effort in C++. Maybe there's already a C++ widget set out there that we could use to start, like wxWidgets, maybe something else, maybe something new. Either way, it's time for C++ developers to start thinking about what this all means to them.
At any rate, if it is about making the Web the OS as we've been trying to do for centuries now, what does it mean to C++ application developers? How do they make their applications relevant in this new world? Is it all over? Do we throw away our C++ compilers and pick up a book on PHP?
I strongly believe there will always be a role for a close to the silicon programming language like C++. Whether it's for resource constrained devices like mobile platforms, or whether it's for high performance apps like image processing or simulations, there's still that need.
What may change is how these C++ apps communicate with the user. I can easily imagine a Web-based UI for C++ apps, similar to other Web 2.0 platforms. Who says the server side needs to be Java or PHP? It could easily be a C++ app. What we need, though, is a clean way to program such a UI. C++ widget programming has always been a challenge, but wait until you change the paradigm like this.
This is one reason I'm keeping an eye on the "Webification of SWT" part of the Eclipse e4 project. The lessons learned and the technology choices made there should be portable to a similar effort in C++. Maybe there's already a C++ widget set out there that we could use to start, like wxWidgets, maybe something else, maybe something new. Either way, it's time for C++ developers to start thinking about what this all means to them.
Monday, September 01, 2008
Google has their own browser!???
Apparently the word leaked on an unofficial Google blog site and they followed up with an "oops" official blog post. Either way, the word is out and the web browser "industry" is in for a shake up. Google is releasing their own web browser called Google Chrome. Apparently it includes pieces from Webkit (I'm guessing the browser part) and Firefox (I'm guessing the chrome part) and will be developed as an open source project.
The first beta will be released tomorrow (Tuesday). I've heard rumors but always dismissed them. Why would they do that when we have a handful of pretty good browsers already. I guess the rumors were true and given the beta comes out now, it's been in the works for a while.
But still, you've got to ask why. Why couldn't they just contribute the stuff the felt was important to Firefox or Webkit. I'm going to guess that it's because sometimes getting your ideas into an open source project is hard. Everyone with a few open source miles under their belt knows how hard it is to influence a community at times and this isn't exactly the first fork in the industry. And when you have the resources and experience Google has, I guess it made more sense for them to fork.
My favorite quote is from the cnet news article where I first stumbled on the news: "Open sourcing the code is a smart way to avoid the 'Google wants to take over the world' fear, but it seems that Google has ambitions to create a comprehensive Internet operating system, including a browser, applications, middleware and cloud infrastructure."
Very intriguing. And this is one of the reasons I'm very interested in Android. Because that's what it is, an internet operating system for mobile. It isn't much of a stretch to take it beyond the cell phone so it'll be very interesting to watch where this goes. (And, yeah, I think Microsoft should be paying attention to this.)
The first beta will be released tomorrow (Tuesday). I've heard rumors but always dismissed them. Why would they do that when we have a handful of pretty good browsers already. I guess the rumors were true and given the beta comes out now, it's been in the works for a while.
But still, you've got to ask why. Why couldn't they just contribute the stuff the felt was important to Firefox or Webkit. I'm going to guess that it's because sometimes getting your ideas into an open source project is hard. Everyone with a few open source miles under their belt knows how hard it is to influence a community at times and this isn't exactly the first fork in the industry. And when you have the resources and experience Google has, I guess it made more sense for them to fork.
My favorite quote is from the cnet news article where I first stumbled on the news: "Open sourcing the code is a smart way to avoid the 'Google wants to take over the world' fear, but it seems that Google has ambitions to create a comprehensive Internet operating system, including a browser, applications, middleware and cloud infrastructure."
Very intriguing. And this is one of the reasons I'm very interested in Android. Because that's what it is, an internet operating system for mobile. It isn't much of a stretch to take it beyond the cell phone so it'll be very interesting to watch where this goes. (And, yeah, I think Microsoft should be paying attention to this.)
Friday, August 29, 2008
Where's Wascana 1.0?
For those who haven't heard of Wascana, it's a lake in the center of my birthplace, Regina, Saskatchewan, Canada. It's a beautiful oasis in the middle of the bald Canadian prairies and my last trip there inspired me to name my Eclipse CDT distribution for Windows desktop programming after it.
Around this time last year I realized that school was about to start and I rushed out the first release of Wascana 0.9.3. To date I've had almost 9,000 downloads of it showing me that there is interest and a need out there for such a package.
My plan was to get Wascana 1.0 ready for this school year. But my summer has been very busy and I haven't had a chance to work on it. But hear me now and believe me later (I'm sure that was in an old Saturday Night Live sketch somewhere), it is still on my roadmap. For one thing, I really want to make it a showcase for the Eclipse p2 provisioning system showing how you can build a feature rich install and update environment for your whole IDE, not just the Eclipse bits.
Aside from that I want to add the boost C++ libraries to the package. Boost is a very full C++ template library that gives you a lot of the library functionality that makes Java so good, and it's often a showcase for new technologies that end up in the C++ standard anyway.
I'm also waiting for an official release of gcc 4.3.1 for MinGW, to give us the latest and greatest compiler technology from GNU with super good optimization and support for OpenMP for parallel programming. There's also the newest gdb debugger that gives pending breakpoint support so we can get rid of a lot of the kludges we had to put in place to support this kind of thing in the CDT. Unfortunately, Windows debugging for MSVC support isn't as complete as I'd hoped, but there has been progress as part of the Target Communication Framework (TCF) work at Eclipse, so we will get there sooner or later.
And, of course, there's Ganymede, including the latest CDT 5.0.1 which will be coming out with the Ganymede SR1 in a couple of weeks. CDT had some really awesome improvements, including new refactoring support, in the 5.0 stream.
So for those waiting, I'm glad your a patient bunch. The wait will be worth it for this critical piece of my continuing effort to get the grassroots C++ programmers and hobbyists, many of whom are working on Windows, into the Eclipse world.
Around this time last year I realized that school was about to start and I rushed out the first release of Wascana 0.9.3. To date I've had almost 9,000 downloads of it showing me that there is interest and a need out there for such a package.
My plan was to get Wascana 1.0 ready for this school year. But my summer has been very busy and I haven't had a chance to work on it. But hear me now and believe me later (I'm sure that was in an old Saturday Night Live sketch somewhere), it is still on my roadmap. For one thing, I really want to make it a showcase for the Eclipse p2 provisioning system showing how you can build a feature rich install and update environment for your whole IDE, not just the Eclipse bits.
Aside from that I want to add the boost C++ libraries to the package. Boost is a very full C++ template library that gives you a lot of the library functionality that makes Java so good, and it's often a showcase for new technologies that end up in the C++ standard anyway.
I'm also waiting for an official release of gcc 4.3.1 for MinGW, to give us the latest and greatest compiler technology from GNU with super good optimization and support for OpenMP for parallel programming. There's also the newest gdb debugger that gives pending breakpoint support so we can get rid of a lot of the kludges we had to put in place to support this kind of thing in the CDT. Unfortunately, Windows debugging for MSVC support isn't as complete as I'd hoped, but there has been progress as part of the Target Communication Framework (TCF) work at Eclipse, so we will get there sooner or later.
And, of course, there's Ganymede, including the latest CDT 5.0.1 which will be coming out with the Ganymede SR1 in a couple of weeks. CDT had some really awesome improvements, including new refactoring support, in the 5.0 stream.
So for those waiting, I'm glad your a patient bunch. The wait will be worth it for this critical piece of my continuing effort to get the grassroots C++ programmers and hobbyists, many of whom are working on Windows, into the Eclipse world.
Tuesday, August 26, 2008
Open Source Handhelds
Quite a while ago now I posted about the open source gaming device from Korea know as the GP2X. At the end of the day, it ended up with a storied history and while I love the concept of a handheld mobile device for which you can write your own applications, their execution as a company out side of Korea wasn't that great and only a distributor in the UK was able to make any kind of splash with it.
At any rate, I found on Slashdot that they have announced a new generation of the product called the Wiz. The links lead you to the UK site and a big JPEG of the brochure in English. The specs look pretty good, ARM9 processor at 533MHz, 3D accelerated graphics, Linux of course, and support for audio and video making it a pretty cool multimedia gaming machine, for which you can write your own applications. And hopefully they'll be a bit more successful at delivering it than the last one.
But there are other choices for such open handheld devices. One of the commentors on Slashdot pointed to another one called OpenPandora. It has better specs, including the TI OMAP3 which is a monster ARM Cortex-A8 processor with full OpenGL 2.0 ES (i.e. with programmable shaders) graphics. It comes at what I believe will be a higher price point than the Wiz, but it is more powerful and has a QWERTY keyboard.
Looking at this in combination with the Linux mobile phone thrusts going on reminds me of the early days of the PC. Lots of different platforms doing specialized things that beacon the hobbyist programmer to come play - VIC 20, Commodore 64, Trash-80, ... The PC is relatively boring today, but maybe these devices can bring in a new generation of programmer that loves to play like we did "back in the day".
At any rate, I found on Slashdot that they have announced a new generation of the product called the Wiz. The links lead you to the UK site and a big JPEG of the brochure in English. The specs look pretty good, ARM9 processor at 533MHz, 3D accelerated graphics, Linux of course, and support for audio and video making it a pretty cool multimedia gaming machine, for which you can write your own applications. And hopefully they'll be a bit more successful at delivering it than the last one.
But there are other choices for such open handheld devices. One of the commentors on Slashdot pointed to another one called OpenPandora. It has better specs, including the TI OMAP3 which is a monster ARM Cortex-A8 processor with full OpenGL 2.0 ES (i.e. with programmable shaders) graphics. It comes at what I believe will be a higher price point than the Wiz, but it is more powerful and has a QWERTY keyboard.
Looking at this in combination with the Linux mobile phone thrusts going on reminds me of the early days of the PC. Lots of different platforms doing specialized things that beacon the hobbyist programmer to come play - VIC 20, Commodore 64, Trash-80, ... The PC is relatively boring today, but maybe these devices can bring in a new generation of programmer that loves to play like we did "back in the day".
Android SDK goes beta
Well, if you follow the embedded industry even from a distance, the news that the Android SDK has gone beta is old news by now. I've been so busy p2-izing our upcoming Wind River products that I haven't had time to write here. Time to get my priorities straight :).
Any whoo, there's a lot of competition all of a sudden for mind share in the mobile Linux game. Android has been pretty quiet lately but they've clearly been busy beavers and a real Android-based device seems imminent, so it's time to take them seriously.
The only thing I'm really waiting for from them, however, is open sourcing of their Dalvik VM technology (can't call it Java since it's not Java, but it's Java...). For Java to truly take off in the embedded space, we need a good VM that works in resource constrained environments and runs well on relatively slow processors. Oh, yeah, and it has to be freely available for the kids to play with it. It's there in the Android SDK, but it would be cool to have the source to see how hard it would be to port to other mobile Linux platforms.
Because there are other players in this game and they actually seem to be ahead at this point. OpenMoko has already shipped a new version of their Neo FreeRunner phone. LiMo has a healthy stable of partners with a number of them already shipping devices as well.
So is there room for all of them? No. There is not. As Donald Smith conjectured recently, mobile is becoming more about the software stack than the hardware. Luckily we have more hardware than stacks at the moment, but not by much. We need to see some consolidation here soon so that application developers can start building those killer apps without having to port them to umpteen different environments.
BTW, Equinox running on Dalvik would be very cool. I'm guessing it's not easy. But is this in the works by anyone?
Any whoo, there's a lot of competition all of a sudden for mind share in the mobile Linux game. Android has been pretty quiet lately but they've clearly been busy beavers and a real Android-based device seems imminent, so it's time to take them seriously.
The only thing I'm really waiting for from them, however, is open sourcing of their Dalvik VM technology (can't call it Java since it's not Java, but it's Java...). For Java to truly take off in the embedded space, we need a good VM that works in resource constrained environments and runs well on relatively slow processors. Oh, yeah, and it has to be freely available for the kids to play with it. It's there in the Android SDK, but it would be cool to have the source to see how hard it would be to port to other mobile Linux platforms.
Because there are other players in this game and they actually seem to be ahead at this point. OpenMoko has already shipped a new version of their Neo FreeRunner phone. LiMo has a healthy stable of partners with a number of them already shipping devices as well.
So is there room for all of them? No. There is not. As Donald Smith conjectured recently, mobile is becoming more about the software stack than the hardware. Luckily we have more hardware than stacks at the moment, but not by much. We need to see some consolidation here soon so that application developers can start building those killer apps without having to port them to umpteen different environments.
BTW, Equinox running on Dalvik would be very cool. I'm guessing it's not easy. But is this in the works by anyone?
Saturday, August 16, 2008
Eye Candy on the Linux Desktop
My crusade for a better Linux desktop continues. After reading a recent rant from someone at the Inq and recent predictions on what Linux will look like in 4 years time, I thought I'd give another shot at improving my Linux desktop. I've been using it heavily from the command line for manufacturing media for upcoming Wind River product using our Eclipse p2 based installer/generator and for mucking around with ClearCase. I can do all that from putty on my Windows machine. But it would be easier if I could just do it and everything else I need to do right on the Linux desktop.
What I was really after was the 3D effects offered by the Compiz Fusion compositing window manager for my GNOME desktop. After a recent bad experience installing a security upgrade for Fedora 9 which totally killed my machine (no boot up for you), I'm back on Ubuntu 8.04. But, alas, I had to install the proprietary drivers for my ATI video card before I could turn on the effects, which is another can of worms I'll leave for now. But once I did, I was up and flying with some wobbly windows and spinning cubes and windows flying all over the place.
I haven't used Mac OS X or Vista seriously, but I can't imagine any eye candy they would have that Compiz doesn't have. So in that sense, I get the feeling that Linux is making huge strides forward. I still haven't figured out how to get fonts as crisp as I get on Windows but I imagine it could be done. It does indeed appear we're not that far away from a champion desktop for Linux (sorry, watching too much Olympics and I'm finding too many parallels between Linux desktop and the ability for Canadian athletes to win medals, 4th place is great, but...).
But I really liked what the guy said in the article about Linux in 2012. He predicts we will get there, but that it's going to take "for pay" distributions of Linux to take us there. Free software isn't going to do it. And there's good reason. Windows and Mac look so good because of the proprietary software that makes it happen. If we want that on Linux, we're going to have to pay for it, just like we do for Windows and Mac OS X.
We're going to have to pay for the licences to the software that legally plays MP3s and shows DVDs and cleans up my fonts and for someone to make it all work on our laptops without having to edit anything in /etc. That's just the economic reality of it. And I for one have no problem with that. Because I believe you get what you pay for. Free software is great for commodity software like kernels and windowing systems and IDEs written in Java ;) where there's lots of people to help build them. But it takes rare skill to make a great desktop environment. And the guys with those skills hold the cards and probably want to profit from their fortune. To get a great desktop on top of that great OS, it's worth it.
What I was really after was the 3D effects offered by the Compiz Fusion compositing window manager for my GNOME desktop. After a recent bad experience installing a security upgrade for Fedora 9 which totally killed my machine (no boot up for you), I'm back on Ubuntu 8.04. But, alas, I had to install the proprietary drivers for my ATI video card before I could turn on the effects, which is another can of worms I'll leave for now. But once I did, I was up and flying with some wobbly windows and spinning cubes and windows flying all over the place.
I haven't used Mac OS X or Vista seriously, but I can't imagine any eye candy they would have that Compiz doesn't have. So in that sense, I get the feeling that Linux is making huge strides forward. I still haven't figured out how to get fonts as crisp as I get on Windows but I imagine it could be done. It does indeed appear we're not that far away from a champion desktop for Linux (sorry, watching too much Olympics and I'm finding too many parallels between Linux desktop and the ability for Canadian athletes to win medals, 4th place is great, but...).
But I really liked what the guy said in the article about Linux in 2012. He predicts we will get there, but that it's going to take "for pay" distributions of Linux to take us there. Free software isn't going to do it. And there's good reason. Windows and Mac look so good because of the proprietary software that makes it happen. If we want that on Linux, we're going to have to pay for it, just like we do for Windows and Mac OS X.
We're going to have to pay for the licences to the software that legally plays MP3s and shows DVDs and cleans up my fonts and for someone to make it all work on our laptops without having to edit anything in /etc. That's just the economic reality of it. And I for one have no problem with that. Because I believe you get what you pay for. Free software is great for commodity software like kernels and windowing systems and IDEs written in Java ;) where there's lots of people to help build them. But it takes rare skill to make a great desktop environment. And the guys with those skills hold the cards and probably want to profit from their fortune. To get a great desktop on top of that great OS, it's worth it.
Monday, August 11, 2008
How many threads? No way!
Well, I thought I was being sneaky when I googled for the Intel Larrabee paper that is being presented tomorrow at SIGGRAPH and thought you had to be an ACM member to get a copy but then found it on the Intel site. Everyone else seems to have found it too. To save you the hastle, here it is. I found the link today on Wikipedia so apparently it's no longer secret.
Anyway, I'm more curious about it than anything. And I guess the biggest question I had was how many cores the thing is supposed to have. This will help me measure how pressing the need is to figure out how to program many threaded applications without Joe programmer's head exploding.
Well there's no actual product announcement in the paper, which I guess is the right thing since it's a conference paper aimed at getting graphics programmers interested in their architecture. But the performance charts give a hint. They show the number of cores needed to make some of the popular recent games hit 60 frames per second where you generally need between 24 and 32 cores. They then show some charts showing scalability up to 64 cores. Given that, I think it's safe to say we'll see 24-32 core Larrabees in the not too distant future and grow from there.
But wait, there's more. Each core has 4 threads of execution to help ensure that the cores are kept busy while waiting for cache and memory and I/O and stuff. That gives you up 256 concurrent threads in the 64-core monster and 128 in the regular 32-core machine. That's a lot of threads. And, yes, it'll be hard to write applications that can get the maximum performance from these.
One other thing I found interesting is that their performance tests were done with the cores running at 1 GHz. That's pretty slow by modern standards. And it explains why they are focusing on graphics co-processor applications where programmers are already trying to figure out how to make things more parallel. If you don't, you're single threaded application running at 1 GHz will be pretty slow (trust me, I have a 667 MHz Pentium III at home, brutal). So until multi-threaded programming becomes more mainstream, don't expect to see one of these things running your Office suite or Eclipse - even though it could.
Anyway, I'm more curious about it than anything. And I guess the biggest question I had was how many cores the thing is supposed to have. This will help me measure how pressing the need is to figure out how to program many threaded applications without Joe programmer's head exploding.
Well there's no actual product announcement in the paper, which I guess is the right thing since it's a conference paper aimed at getting graphics programmers interested in their architecture. But the performance charts give a hint. They show the number of cores needed to make some of the popular recent games hit 60 frames per second where you generally need between 24 and 32 cores. They then show some charts showing scalability up to 64 cores. Given that, I think it's safe to say we'll see 24-32 core Larrabees in the not too distant future and grow from there.
But wait, there's more. Each core has 4 threads of execution to help ensure that the cores are kept busy while waiting for cache and memory and I/O and stuff. That gives you up 256 concurrent threads in the 64-core monster and 128 in the regular 32-core machine. That's a lot of threads. And, yes, it'll be hard to write applications that can get the maximum performance from these.
One other thing I found interesting is that their performance tests were done with the cores running at 1 GHz. That's pretty slow by modern standards. And it explains why they are focusing on graphics co-processor applications where programmers are already trying to figure out how to make things more parallel. If you don't, you're single threaded application running at 1 GHz will be pretty slow (trust me, I have a 667 MHz Pentium III at home, brutal). So until multi-threaded programming becomes more mainstream, don't expect to see one of these things running your Office suite or Eclipse - even though it could.
Friday, August 08, 2008
Carmack the Magnificent
(BTW, the title of this blog entry is a spin on one of my favorite TV personalities from many years ago, Johnny Carson)
I just finished reading an interview Tom's Games did with John Carmack, the mastermind behind id Software. I love hearing from him. He's very respected in the gaming industry, is a really smart guy, is totally a geek, but has a good eye on the industry. You learn a lot about where gaming is going technology-wise and business-wise by listening to him.
A couple of things he mentioned interested me. He did bring up multi-core computing and how gaming programmers are still trying to figure out how to take advantage of all those extra concurrent threads. As with everything, it's going to really change the way programmers think. In what I'm sure was a Freudian slip by the writer, he used the word "paralyze" instead of "parallelize". I think that's exactly what's happening. Programmers are paralyzed as they try to figure out what to do. It goes against everything they've been trained.
On the good news front, though, I've been playing a little with the dataflow programming paradigm and I'm liking the way it makes me think. Essentially you have huge number of processes that have data streams between them. You're program becomes a network of co-operating virtual machines. Makes sense to me but it needs to be tried out on a real application. And I think gaming is that perfect application.
As a side note, John also talks about the iPhone and how it can be a great gaming platform. His wife says it's a terrible phone, which I'm sure it is, but using these things as phones is becoming secondary to the other applications that can run on them. I'm pretty sure that's where the future of mobile devices is headed. Forget the phone, they're just great little network appliances.
I just finished reading an interview Tom's Games did with John Carmack, the mastermind behind id Software. I love hearing from him. He's very respected in the gaming industry, is a really smart guy, is totally a geek, but has a good eye on the industry. You learn a lot about where gaming is going technology-wise and business-wise by listening to him.
A couple of things he mentioned interested me. He did bring up multi-core computing and how gaming programmers are still trying to figure out how to take advantage of all those extra concurrent threads. As with everything, it's going to really change the way programmers think. In what I'm sure was a Freudian slip by the writer, he used the word "paralyze" instead of "parallelize". I think that's exactly what's happening. Programmers are paralyzed as they try to figure out what to do. It goes against everything they've been trained.
On the good news front, though, I've been playing a little with the dataflow programming paradigm and I'm liking the way it makes me think. Essentially you have huge number of processes that have data streams between them. You're program becomes a network of co-operating virtual machines. Makes sense to me but it needs to be tried out on a real application. And I think gaming is that perfect application.
As a side note, John also talks about the iPhone and how it can be a great gaming platform. His wife says it's a terrible phone, which I'm sure it is, but using these things as phones is becoming secondary to the other applications that can run on them. I'm pretty sure that's where the future of mobile devices is headed. Forget the phone, they're just great little network appliances.
Wednesday, August 06, 2008
How's build working for you?
It's been a crazy couple of months for me. The list of things I need to do has been badly encroaching on my time for Eclipse community work. But it's all been good and we're working on some really cool stuff with p2 internally here at Wind River which should turn into community work as well anyway.
But it's getting time to start my work on e4 and the Eclipse resource model. We've talked a lot in the past about the need for flexibility there and to support other resource models that don't necessarily map to the underlying file system. Even in the last few days we've received inquiries on the cdt-dev list about supporting Visual Studio-style projects in this manner (from a guy with an e-mail address of nvidia.com - quite interesting). So this is what we've meant by flexible resources and what we plan on addressing.
The question I'm starting to ask myself is whether we should be looking at the build side of the resource model as well. If you come from the Makefile centric view of the world, the Eclipse build system is very bizarre indeed. I'm not sure of the history of how it got to be that way, but it was our first real interaction with the Eclipse Platform team, to somehow get Eclipse to build CDT projects correctly. There's still a lot of magic there that probably could be simplified if we made the build model more flexible as well.
Also we have a hell of a time co-ordinating loading the CDT build model data from our magic .cproject file at the right time and in a scalable and non-deadlockable way. Sometimes I just wish that the .project file and the code that manages it was more flexible as well so I can have our build data loaded at the same time the rest of the project information is loaded. (Yes you can do a little of that now but not easily with the complex data we have for our build configurations, tool chains, option settings, etc).
Anyway, I don't know how many people are building IncrementalProjectBuilders out there (and, yes, the weirdness does start there). But I was wondering if other plug-in developers are also facing issues like this.
But it's getting time to start my work on e4 and the Eclipse resource model. We've talked a lot in the past about the need for flexibility there and to support other resource models that don't necessarily map to the underlying file system. Even in the last few days we've received inquiries on the cdt-dev list about supporting Visual Studio-style projects in this manner (from a guy with an e-mail address of nvidia.com - quite interesting). So this is what we've meant by flexible resources and what we plan on addressing.
The question I'm starting to ask myself is whether we should be looking at the build side of the resource model as well. If you come from the Makefile centric view of the world, the Eclipse build system is very bizarre indeed. I'm not sure of the history of how it got to be that way, but it was our first real interaction with the Eclipse Platform team, to somehow get Eclipse to build CDT projects correctly. There's still a lot of magic there that probably could be simplified if we made the build model more flexible as well.
Also we have a hell of a time co-ordinating loading the CDT build model data from our magic .cproject file at the right time and in a scalable and non-deadlockable way. Sometimes I just wish that the .project file and the code that manages it was more flexible as well so I can have our build data loaded at the same time the rest of the project information is loaded. (Yes you can do a little of that now but not easily with the complex data we have for our build configurations, tool chains, option settings, etc).
Anyway, I don't know how many people are building IncrementalProjectBuilders out there (and, yes, the weirdness does start there). But I was wondering if other plug-in developers are also facing issues like this.
Monday, July 28, 2008
Going with the data-flow
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.
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.
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.
Wednesday, May 28, 2008
A Pragmatic E4
So, yes, I was at the e4 summit last week. I've been meaning to blog about it but it's taking some time for me to realize what it was all about. And I think I am finally able to put it into words.
For those who don't know the history, e4 kinda tripped into existence as a side effect of the creation of an Eclipse incubator project to allow people working on it to check in prototypes and stuff. It was pretty innocent but it did scare a lot of people with the appearance that a new Eclipse platform was being developed without guidance from the community.
Of course, the dust has settled and fears subsided and IBM hosted the e4 summit last week to give people the opportunity to offer their guidance and, more importantly, to offer their help. It was a good, yet standard summit in my view. Lots of good ideas, but few actionable items, especially beyond what has already been actioned.
And to be honest, that's the way it probably should be. If anyone thinks that we can write a whole new platform and discard backwards compatability, they're kidding themselves. I think we'd all be fired if we came to our product teams with a plan like that. So I'm not worried in the least about that.
I think McQ has the right strategy and he tried hard to get the point across. You can rewrite the world with the best API and architecture and write a facade over top to let old plug-ins continue to work with as little change as possible. You can have your cake and eat it to. And, yes, it's a lot more work. But as I said, we'd be fired if we didn't do that. That's what will constrain the community from going hog wild on e4. And that's a good thing.
So if e4 isn't a great new platform, what is it? Lots of people are wondering that and I'm sure we all have different answers. To me, what e4 is, is the opening up of the platform to new contributors. It's a change in mindset of the platform team who have been maniacally focused on controlling change (justifiably so in my view) that they have scared off or rejected many a contribution. e4 gives them a chance to loosen up and be more accepting. And it is really up to the rest of us to take advantage and get in there and make the tactical improvements we need while this door is open. It would be our own fault to miss this great opportunity.
For those who don't know the history, e4 kinda tripped into existence as a side effect of the creation of an Eclipse incubator project to allow people working on it to check in prototypes and stuff. It was pretty innocent but it did scare a lot of people with the appearance that a new Eclipse platform was being developed without guidance from the community.
Of course, the dust has settled and fears subsided and IBM hosted the e4 summit last week to give people the opportunity to offer their guidance and, more importantly, to offer their help. It was a good, yet standard summit in my view. Lots of good ideas, but few actionable items, especially beyond what has already been actioned.
And to be honest, that's the way it probably should be. If anyone thinks that we can write a whole new platform and discard backwards compatability, they're kidding themselves. I think we'd all be fired if we came to our product teams with a plan like that. So I'm not worried in the least about that.
I think McQ has the right strategy and he tried hard to get the point across. You can rewrite the world with the best API and architecture and write a facade over top to let old plug-ins continue to work with as little change as possible. You can have your cake and eat it to. And, yes, it's a lot more work. But as I said, we'd be fired if we didn't do that. That's what will constrain the community from going hog wild on e4. And that's a good thing.
So if e4 isn't a great new platform, what is it? Lots of people are wondering that and I'm sure we all have different answers. To me, what e4 is, is the opening up of the platform to new contributors. It's a change in mindset of the platform team who have been maniacally focused on controlling change (justifiably so in my view) that they have scared off or rejected many a contribution. e4 gives them a chance to loosen up and be more accepting. And it is really up to the rest of us to take advantage and get in there and make the tactical improvements we need while this door is open. It would be our own fault to miss this great opportunity.
Monday, May 26, 2008
Pheonix has landed! A woo-hoo moment
Reaching new heights in geekness, I watched the landing of the Phoenix spacecraft on Mars last night live over the web via NASA TV. I don't know, I find there's lots of drama in space missions. It's an incredible task. One of the mission managers compared it to hitting a hole in one in Australia from a tee in Ottawa (ok, he said Washington but Ottawa is about the same distance :). Another manager closer to the action added, "with Australia moving". The good news is that they pinned it, relatively, missing only by 20km, rimming it around the hole before dropping it if you will.
The highlight for me was watching the jubilation as the guy called out that the spacecraft had reported a touchdown detected event. The gratification of years of work wrapped up in a single (probably) 2 byte event report is well deserved. That little report required so much technology to be working, it's mind boggling.
That feeling of jubilation is what I call a woo-hoo moment. Mind you nothing I've done compares to the moment these guys had, but I think it's an important aspect of all software development. It's these little moments that help you realize all that hard work you've put into the project actually works and you can do a little celebration (usually throwing my hands into the air for me and yelling "yes" :). It helps get the adrenalin going and really gives you the energy to start working towards the next one.
In my career I've had a number of these moments and I always try to schedule them into the projects I'm working on. And these moments I don't soon forget: the first run of an external code generated state machine from ObjecTime Developer happened a long time ago and I still remember when it happened. My work on the CDT has had a few too. The first outline view from CDT's first parser, the first content assist (which was a surprise since the Neifer just did a couple of tweaks to the binding resolution code and it just worked), and the first complete index of the Firefox source using the new Fast indexer that beat my set goal of 20 minutes (it's now around 13 minutes the last I looked). And more recently, I have the first install of Wind River product based on p2 (the DVD is hanging on my wall :).
I'm sure we all have moments like this throughout our lives. For software development, this is why I think iterative development is the only way to go. Not only does it give you a chance to show your customers progress and get their feedback, it lets you schedule in gratuitous woo-hoo moments.
The highlight for me was watching the jubilation as the guy called out that the spacecraft had reported a touchdown detected event. The gratification of years of work wrapped up in a single (probably) 2 byte event report is well deserved. That little report required so much technology to be working, it's mind boggling.
That feeling of jubilation is what I call a woo-hoo moment. Mind you nothing I've done compares to the moment these guys had, but I think it's an important aspect of all software development. It's these little moments that help you realize all that hard work you've put into the project actually works and you can do a little celebration (usually throwing my hands into the air for me and yelling "yes" :). It helps get the adrenalin going and really gives you the energy to start working towards the next one.
In my career I've had a number of these moments and I always try to schedule them into the projects I'm working on. And these moments I don't soon forget: the first run of an external code generated state machine from ObjecTime Developer happened a long time ago and I still remember when it happened. My work on the CDT has had a few too. The first outline view from CDT's first parser, the first content assist (which was a surprise since the Neifer just did a couple of tweaks to the binding resolution code and it just worked), and the first complete index of the Firefox source using the new Fast indexer that beat my set goal of 20 minutes (it's now around 13 minutes the last I looked). And more recently, I have the first install of Wind River product based on p2 (the DVD is hanging on my wall :).
I'm sure we all have moments like this throughout our lives. For software development, this is why I think iterative development is the only way to go. Not only does it give you a chance to show your customers progress and get their feedback, it lets you schedule in gratuitous woo-hoo moments.
Monday, May 19, 2008
Just call me a p2 fanboy
There's been a lot of bashing of p2 lately by blogs on Planet Eclipse. They seem to revolve around the lack of support for extension locations. I've never used extension locations, and I hate the fact that for whatever reason you would need to manage installs yourself by hacking around the file system.
p2, IMHO, is awesome. It manages installs as good as any install management system I've seen. It tracks versions, it manages dependencies with capabilities which is absolutely the right way to do it. It allows you to install things other than eclipse plug-ins thanks to the extensibility provides by touch points and repositories. When we're done you'll be able to everything your favorite install manager can do and more. From where I sit p2 will change the install industry.
So yeah, extension locations aren't supported any more. And I'm probably not the best person to speak on whether losing them matters. But someone needs to stand up for p2 because it is much needed. And I'm sure you can live without extension locations. I think the worse mistake was providing them to begin with.
p2, IMHO, is awesome. It manages installs as good as any install management system I've seen. It tracks versions, it manages dependencies with capabilities which is absolutely the right way to do it. It allows you to install things other than eclipse plug-ins thanks to the extensibility provides by touch points and repositories. When we're done you'll be able to everything your favorite install manager can do and more. From where I sit p2 will change the install industry.
So yeah, extension locations aren't supported any more. And I'm probably not the best person to speak on whether losing them matters. But someone needs to stand up for p2 because it is much needed. And I'm sure you can live without extension locations. I think the worse mistake was providing them to begin with.
Friday, May 16, 2008
CDT 5.0 looks good, now looking ahead
The CDT gang has put together a list of new features that are coming out with CDT 5.0 in a few weeks. Check it out here. There has been a lot of work further improving the indexer and we have a new refactoring framework with a few refactorings available. And there has been a little work on the build and debug side as well.
It was a good sign this release that we had no major architectural changes and got to focus on quality. There is a new scanner/preprocessor for the CDT's parsers but, trust me, that was much needed and Markus S did such a great job that we hardly noticed the change. Compared to the new indexer framework in 3.1 and the new build framework in 4.0 things went much more smoothly this time.
As I start to work on Wascana 1.0 based on this great work, I still notice a couple of areas that we need to work on for next year's 5.1. First of all is the tighter intergration of the Debug Services Framework (DSF) that is being built by the Device Debugging project. This is a pretty cool framework that is highly asynchronous and extendible. I am working on integrating MinGW's gdb with it as an exemplary integration both to help me learn DSF and to show others how to use it.
But to make this integration seamless, we really need to do something about the Launch Configurations. Right now DSF provides it's own set, meaning if you have CDT's current debug framework and DSF installed at the same time you get two sets. That's going to be terribly confusing. And, from what I hear, every vendor that integrates their own debuggers with the CDT add in their own sets. I'd like to see if we can get a common launch framework in place to help solve this, assuming there's support from the community for that.
The other big issue we've got to address is the CDT build system. We've tried to support two modes of build, using external build systems, and using Visual Studio-like internal build. External is easy. But, unfortunately, my feeling is that we've made things too complicated on the "managed" build side. There has been some great work done up until now by the committers, but we need to make sure we're meeting the needs of the community and either address them or provide the extensibility to allow them to do what they need but still provide a common user experience.
My real objective is to provide a common user experience for all CDT users whether they're using a commercial product or the standard open one. That means unifying the workflows for everyone. Maybe then it'll make financial sense for someone or a group of someones to write a CDT book to serve all of the CDT community.
It was a good sign this release that we had no major architectural changes and got to focus on quality. There is a new scanner/preprocessor for the CDT's parsers but, trust me, that was much needed and Markus S did such a great job that we hardly noticed the change. Compared to the new indexer framework in 3.1 and the new build framework in 4.0 things went much more smoothly this time.
As I start to work on Wascana 1.0 based on this great work, I still notice a couple of areas that we need to work on for next year's 5.1. First of all is the tighter intergration of the Debug Services Framework (DSF) that is being built by the Device Debugging project. This is a pretty cool framework that is highly asynchronous and extendible. I am working on integrating MinGW's gdb with it as an exemplary integration both to help me learn DSF and to show others how to use it.
But to make this integration seamless, we really need to do something about the Launch Configurations. Right now DSF provides it's own set, meaning if you have CDT's current debug framework and DSF installed at the same time you get two sets. That's going to be terribly confusing. And, from what I hear, every vendor that integrates their own debuggers with the CDT add in their own sets. I'd like to see if we can get a common launch framework in place to help solve this, assuming there's support from the community for that.
The other big issue we've got to address is the CDT build system. We've tried to support two modes of build, using external build systems, and using Visual Studio-like internal build. External is easy. But, unfortunately, my feeling is that we've made things too complicated on the "managed" build side. There has been some great work done up until now by the committers, but we need to make sure we're meeting the needs of the community and either address them or provide the extensibility to allow them to do what they need but still provide a common user experience.
My real objective is to provide a common user experience for all CDT users whether they're using a commercial product or the standard open one. That means unifying the workflows for everyone. Maybe then it'll make financial sense for someone or a group of someones to write a CDT book to serve all of the CDT community.
Wednesday, May 14, 2008
It's all good, but not enough D's
Well, I think I'm finished my journey into Flash-land. It was an interesting experience. I'm glad I took a deeper look at it and gained an understanding about what the fuss was all about. The deeper look also left me wondering how free the Flash run-time components for devices will really be and how they'll actually deliver bits that will run on your favorite device without really opening the source, or at least making it public. But the technology is very interesting and I'd love to see animated UIs on devices become more common place.
But at the end of it, it left me wanting. The big new thing we're seeing on the desktop is 3D enabled UIs. 2D is good, but I think there are some really exciting things you can do when you add another D to the mix. You can see some of the potential in the UIs presented by console video games. I'll never forget my first eye opener with the old Rogue Squadron Star Wars game on our first video console, the Nintendo 64, and entering your name with the 3D spinning wheel of letters. It was fun and since you didn't have a keyboard it made the arduous task a little more pleasant.
What I think is missing, though, is a commonly available widget set that makes it easy to program 3D UIs. There may be some out there, but I'd like to see them become more mainstream. And as more and more devices come with 3D hardware accelerated graphic circuitry embedded in their processors and OpenGL ES 3D graphics API for devices becoming more ubiquitous, I'm hoping the industry can take a more serious look at this. Devices are becoming less resource constrained as we go, but they'll always be UI constrained. Maybe 3D can help.
But at the end of it, it left me wanting. The big new thing we're seeing on the desktop is 3D enabled UIs. 2D is good, but I think there are some really exciting things you can do when you add another D to the mix. You can see some of the potential in the UIs presented by console video games. I'll never forget my first eye opener with the old Rogue Squadron Star Wars game on our first video console, the Nintendo 64, and entering your name with the 3D spinning wheel of letters. It was fun and since you didn't have a keyboard it made the arduous task a little more pleasant.
What I think is missing, though, is a commonly available widget set that makes it easy to program 3D UIs. There may be some out there, but I'd like to see them become more mainstream. And as more and more devices come with 3D hardware accelerated graphic circuitry embedded in their processors and OpenGL ES 3D graphics API for devices becoming more ubiquitous, I'm hoping the industry can take a more serious look at this. Devices are becoming less resource constrained as we go, but they'll always be UI constrained. Maybe 3D can help.
Wednesday, May 07, 2008
Flash on the Brain
I hate it when that happens. A shiny object flies by and I can't sleep until I catch it. So I was up until 3 a.m. last night trying to figure out what Adobe Air/Flex/Flash/ActionScript was all about. It's actually pretty interesting stuff technically. But as a number of people commented when I brought it up a couple of days ago, you do get the sense of vendor lock in, at least for now. But the specs are all open now, so open source implementations of this stuff at least have a fighting chance.
So why do I care about Flash (other than my insatiable need to learn as much as I can about the software industry)? Well, it fits in with my interest in mobile devices, especially those based on embedded Linux. As these devices get more powerful and have bigger screens, the line between laptop and mobile device is going to blur. And I think the expectations of users on the UI for these devices is going to grow as well. Everyone oos and ahs over the iPhone UI. It's setting the bar.
But looking at a traditional embedded Linux box with a UI, does it make sense to run X Windows on it? X is horrible and antiquated. And it's very hard to build flashy (sorry about the pun) UIs with it. It certainly wasn't intended for resource constrained devices. Mind you the old X Terminals were pretty much embedded devices, but then where are they now...
So what are the alternatives? DirectFB looks very promising and is growing in popularity in the embedded world. It gives you an nice API over the graphics hardware and input devices that let you build your UI as low level as you need. But it does require you to build a UI from scratch.
So this is the architecture that piqued my interest: Adobe AIR (which include Flash and the WebKit browser) running on DirectFB. Which then opens up other interesting architectures. Like mobile devices turning into web appliances that let you work connected or disconnected (is there a Flash office suite app?). And with Flash's animation, video, and audio capabilities, you could build a pretty lively UI. And, from what I hear, there are a lot of graphic artists who have learned Flash who could give us a hand.
Now, I have no links to Adobe and this only crossed my mind as they "opened" up the technology with the Open Screen project. But if this move helps them build momentum in the mobile space, it opens up a lot of opportunities for mobile software developers, and graphic artists for that matter...
So why do I care about Flash (other than my insatiable need to learn as much as I can about the software industry)? Well, it fits in with my interest in mobile devices, especially those based on embedded Linux. As these devices get more powerful and have bigger screens, the line between laptop and mobile device is going to blur. And I think the expectations of users on the UI for these devices is going to grow as well. Everyone oos and ahs over the iPhone UI. It's setting the bar.
But looking at a traditional embedded Linux box with a UI, does it make sense to run X Windows on it? X is horrible and antiquated. And it's very hard to build flashy (sorry about the pun) UIs with it. It certainly wasn't intended for resource constrained devices. Mind you the old X Terminals were pretty much embedded devices, but then where are they now...
So what are the alternatives? DirectFB looks very promising and is growing in popularity in the embedded world. It gives you an nice API over the graphics hardware and input devices that let you build your UI as low level as you need. But it does require you to build a UI from scratch.
So this is the architecture that piqued my interest: Adobe AIR (which include Flash and the WebKit browser) running on DirectFB. Which then opens up other interesting architectures. Like mobile devices turning into web appliances that let you work connected or disconnected (is there a Flash office suite app?). And with Flash's animation, video, and audio capabilities, you could build a pretty lively UI. And, from what I hear, there are a lot of graphic artists who have learned Flash who could give us a hand.
Now, I have no links to Adobe and this only crossed my mind as they "opened" up the technology with the Open Screen project. But if this move helps them build momentum in the mobile space, it opens up a lot of opportunities for mobile software developers, and graphic artists for that matter...
Happy Day in Linux-land
Thanks to everyone for their great comments on yesterday's entry on the frustrations I had getting ClearCase running on my new Linux machine. It gave me renewed hope that I could get this to work.
And I did. After reinstalling Fedora 8 as the host OS, I started getting a KVM virtual machine ready. I figured I'd try the new Virtual Machine Manager GUI to do it just like I do with VirtualBox. But when they say it's not ready for prime time, believe them. They're on the right track but to do anything serious, I think you still need to use the command line.
Another hurdle I ran into was running the 32-bit version of RHEL. I guess I should have looked harder at the KVM web page that said SMP was unstable in this configuration. It was. So jumping to the 64-bit version, I was good to go, 4 CPUs and a bridged network connection and all! I installed ClearCase and I'm in business. Now it's time to get some real work done. It was fun and I did learn a lot and gained an appreciation for virtualization, so it was well worth it.
And I did. After reinstalling Fedora 8 as the host OS, I started getting a KVM virtual machine ready. I figured I'd try the new Virtual Machine Manager GUI to do it just like I do with VirtualBox. But when they say it's not ready for prime time, believe them. They're on the right track but to do anything serious, I think you still need to use the command line.
Another hurdle I ran into was running the 32-bit version of RHEL. I guess I should have looked harder at the KVM web page that said SMP was unstable in this configuration. It was. So jumping to the 64-bit version, I was good to go, 4 CPUs and a bridged network connection and all! I installed ClearCase and I'm in business. Now it's time to get some real work done. It was fun and I did learn a lot and gained an appreciation for virtualization, so it was well worth it.
Tuesday, May 06, 2008
Frustrating Day in Linux-land
So I'm busy working with my team at Wind on some new installer work and I need to set up ClearCase to get access to the bits that go into the install. I have this spanking new machine, Quad-core Intel, 4GB RAM, 750GB drive. I really got it so I can run multiple virtual machines on it for testing. But if I could run ClearCase on it too, then I could use it for install builds too.
But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.
So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.
As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.
So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.
But my issue is that ClearCase is only supported on certain enterprise versions of Linux. But I want to try the latest KVM support in Ubuntu. So I first installed Ubuntu 64-bit and gave it a try. Ubuntu's 32-bit support in 64-bit installs is horrible. You have to manually install the 32-bit libraries. That probably should be automatic, but then they are trying to fit on a single CD so maybe it's too much. Unfortunately even with the 32-bit libraries, the perl engine ClearCase ships with crashes. So forget that.
So next up, I tried Fedora 8. It's much closer to the supported Red Hat Enterprise and might have a better chance. And besides, there are some good Eclipse guys at Red Hat and I should be supporting them. The 32-bit libraries were automatically installed (but then it is a 3+ GB DVD). So I got a lot farther. After tricking the ClearCase install scripts into accepting Fedora as a "supported" kernel, I got as far as building the MVFS kernel module.
As I tried to fix those errors, I started to feel like I was porting their module for them. And it was a lot of work. We were going from version 2.6.18 of the Linux kernel to 2.6.24, but given how many APIs changed, it felt like I was going to 3.0 or something. At any rate, it doesn't feel like something I should be investing my time in so I gave up on that.
So I tried the supported RHEL 5. You know what, after installing it and rebooting it. No network. RHEL 5 didn't have a driver for the ethernet on the new machine. For crying out loud (again...). Unfortunately, it's back to Windows for me. At least for now. Hopefully I can tweak ClearCase to make it fast enough to be usable.
Monday, May 05, 2008
MinGW gcc 4.3 lives!
This just in, Aaron LaFramboise has just released an alpha version of gcc 4.3 for MinGW. And, of course, they are looking for testers. I know I will be. You can give it a try to by downloading it off of mingw.org. I've been following the mingw-users mailing list and it's been a great place to discuss issues. It's not too busy but it's been busy enough to be useful.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.
Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.
Friday, May 02, 2008
Open Screen, Another Game Changer?
I just went through some blogs and the Adobe Open Screen web site to try and understand what's going on. If you haven't heard, Adobe is removing licensing restrictions on it's SWF and FLV/F4V file formats that serve us Flash content and all those crazy videos on YouTube and such. In the past, the license on the specs restricted the reader from creating competing players, which has resulted in some pretty weak open source players that relied on the developers reverse engineering and guessing at what the spec is.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.
So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.
Monday, April 28, 2008
Building Windows apps on Linux?
I had this interesting feature request on the Wascana forum. This user would like to use Wascana on Linux to build applications that run on both Linux and Windows. You know, that's an idea that could fly.
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
I noticed that a number of the MinGW developers develop the MinGW tools on Linux. I think they are targeting Wine, the Windows emulation layer for Linux (and if any of them are reading, feel free to fill in the details). And I've seen a number of howto pages describing how to build the MinGW toolchain on Linux. It shouldn't be too much of a leap to build libraries such as wxWidgets in a cross development mode, although if you make too many assumptions that target == host, that won't work.
It's one of the big advantages to the GNU compiler suite, it's ability to build in a cross-compile mode. It's what makes it so popular in embedded. And it's one of the benefits of CDT, to be able to target multiple architectures from the same machine. You wouldn't have to change the CDT at all other than to avoid trying to find MinGW in the Windows registry. Now if only someone would come help make it happen...
Sunday, April 27, 2008
Help! I'm not connected...
I mentioned a couple of weeks ago that I have this idea for a visual programming language with inspiration from UML Action Semantics and the SynthMaker virtual instrument programming environment that came with my Fruity Loops thing.
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
So on my flight down to San Fran for the Embedded Systems Conference last week, I thought I'd take a stab at learning GMF and maybe start plugging away at the idea. I haven't used GMF recently and it looks like there's a lot more automation these days that should help me get going quickly. I downloaded the new Modeling EPP package before I left and gave it a try.
Now, I learn best by walking through examples with the help of tutorials. I fired up the Help system and opened the page for GMF tutorials and it said: "A tutorial that covers the tooling and generative components of GMF is maintained on the GMF Wiki site here." Uh, I'm on a plane. No tutorial for me. So I shut it down and did something else.
Again tonight, I go to start again and clicking the link I get: "Wiki.eclipse.org is currently down for maintenance. We apologize for the inconvenience, but expect to have the site back online shortly." For crying out loud...
Friday, April 25, 2008
C/C++ Top of the Heap, Sort of
The latest TIOBE Programming Community Index has been released. I don't put a lot of weight into surveys like this, especially if I don't know the methodology behind it. As far as I can tell it's based on the popularity of different programming languages as found on the web. I guess it's an all right measure and it co-incides somewhat with my personal observations.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
At any rate, Java comes out on top with a 20% rating which is up 2% from a year ago which is healthy. I'd like to believe the popularity of Eclipse as a tools and application platform has something to do with that.
C was second at close to 15% which is down 1/4%. I still see a whole lot of C, especially in the GNU/Linux community. Almost everything there is still C. And, of course, C is still huge in embedded.
C++ was fifth at close to 10% and a drop of 3/4%. I think C++'s complexity is really hurting it. C++ is built for large scale applications. But Java and C#/VisualBasic (which are 8th and 3rd in the ranking) with their automated memory management are probably better suited for that. Which is too bad since I still believe C++ with its generic programming support is still the most powerful language in common use today.
One thing to consider is that the two languages that CDT supports add up to 25% which makes it top of the heap (see, you can craft any message you want with stats :). But it is pretty obvious that JDT has much more share of the Java market than we do with the C/C++ market. But we're trying.
One thing I did notice with this survey too is that the variety of languages being used is growing over the last five years. I wonder if that speaks to unrest we're having with the languages we have at our disposal. C++ is too complicated, Java is too simple, C doesn't scale, C# is too Microsoft, Basic is too, well, basic. I think the time is coming for something new to rejuvenate us like objects did two decades ago. I wonder what it'll be.
Friday, April 18, 2008
Eclipse for Embedded in San Jose
I'm back in the valley and gave a talk on Eclipse for Embedded at the Embedded Systems Conference. Unfortunately it was at 8:30 in the morning today (Friday) when the exhibition, where all the fun happens, is all over. But I had around 40 people there which was good to see. I also did a shop talk session yesterday at 7:15 which had close to the same number. It was good to see that they made the effort to be there, and it was good to see that almost all of them use the CDT in their daily work.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
I did a walk of the show floor on Wednesday to check out the Eclipse displays. They're still pretty hard to find at least displayed prominently. But all the regulars that I know about at least had Eclipse up on their monitors. I also ran into a new one, ThreadX which has just released a CDT based product. It really does leave Green Hills as the last hold out in the RTOS/embedded tooling community.
The other cool thing that came up is the need for p2 to be a general installer technology. I'm looking at it for Wind River product and I ran into a couple of other vendors who want to do the same. That really confirms that we should be able to build momentum to make this happen. As someone said today on the equinox-dev list, we've always needed an installer for Eclipse. And we've always needed that installer to install everything in our development environment and p2 has that capability.
I wasn't sure I was going to come back next year, but given the number of people I talked to I'm glad I came this year. And given the interest in Eclipse in the embedded developer community, I know they need more classes at this conference to help get them going. We've always struggled to get an Eclipse presence here and it was good to see confirmation that we need to be here.
Friday, April 11, 2008
I love the open source spirit
I came across the web site for the GCC and GNU toolchain developers summit. It's being held here in Ottawa and I am wondering if it might be a good idea to go and get more involved with this community. I do fit into the "enthusiast" category with my work on Wascana and my interest in MinGW. We'll see. I also don't want to take up space that someone more of an enthusiast would like to take.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
At any rate, I came accross this in the FAQ for the event.
Q. What is the legal drinking age in Canada?
A. In Ontario (the provice that Ottawa is in) the legal drinking age is 19. In Quebec (located across the bridge) the legal drinking age is 18.
Well, if that question is frequently asked, either there are a lot of young people coming to this (which is probably true), or it's going to be a great party. It's probably both.
In some ways, the Eclipse culture is quite different than the GNU culture. I think it comes to the fact that Eclipse is much more commercial. But in other ways it's very similar. When you get together at a community event, outside of our suits, the atmosphere is so energetic and positive, you can't help but have a good time.
Friday, April 04, 2008
MinGW entering it's prime?
I have a monitor on files that get released by the MinGW project and I just got a notice that the alpha release of gcc 4.3 for MinGW has just arrived. This follows quite closely behind a tech preview of gdb 6.8 for MinGW which includes a number of improvements to gdb for native Windows development.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
I had almost given up hope that proper GNU toolchain support for native Windows development would arrive, but these recent events and the good work by the contributors of these works has reinvigorated my excitement.
Of course, these new packages will feed into the 1.0 release of Wascana Desktop Developer this summer. I am also working on a p2 based installer for Wascana to help keep users up to date with new releases of the toolchain and libraries. This all gives me hope again that Wascana will become a serious player with the Windows desktop developers. Which will also give our efforts at building a grassroots movement behind the CDT a healthy boost.
Sunday, March 30, 2008
Unexpected surprise in my Fruity Loops
As I mentioned previously here, I am starting to get into making my own electronic music. I've played guitar for many years as a hobby (and I'm nowhere near as good as Steve Northover) but wanted something that I could play with on the road (yes, I was creating music on my flight down and back to EclipseCon). That and it gave me a way to mix hobby and work since I could build software synthesizers using the CDT and Wascana.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
I purchased a copy of FL Studio, which has been previously known as Fruity Loops when I first heard about it a few years ago. It's a goofy name you'd associate with a kids product, but it's now a full fledged digital audio workstation and deserves a grown up name. They just came out with a new version and one of the hidden gems is the inclusion of a product called SynthMaker that lets you build your own software synths using a visual programming environment.
O.K. creating your own synths without having to write C++ code. I guess not all musicians know C++ so I get it. And creating them visually is an interesting approach that newbies should be able to figure out.
But what struck me as I started digging into the sample synths it ships with (which sound awesome BTW) was exactly how powerful a programming environment this is. You create modules which have built in algorithms for everything from audio processing to IO handling to the rendering of the graphics for the synth UI. And then you hook them all up using interface ports and data flow lines.
OMG (the pun is unintended but now that I look at it, it's pretty funny), this is UML Action Semantics in action! Ever since I was involved in the review process for action semantics (including a very awkward call with Jim Rumbaugh - man, was I intimidated by the legend!), I had a vision of a visual programming language based on the concepts. You essentially declare objects and actions that you perform on those objects and link the actions together with data flows and control flows. And now that multi-core computing is becoming all the rage, I figure it's even more important. I think it's the only way programmers will be able to grasp multi-threaded programming, by forcing the code to flow in multiple dimensions instead of the single dimension text streams we have today.
So while I'm taken aback that I found this vision manifested in such a niche product, it helps me realize that this vision could be practical. I can't wait to start diving into it further and getting real experience at programming this way. If it works well, then I can really see the need to manifest this as a general language. And wouldn't this look great written using the Eclipse Modeling projects.
Friday, March 28, 2008
Eclipse p2, sweet!
As we hinted at EclipseCon last week, my team has been evaluating p2 as the framework for our new installer technology. We're essentially coming from an InstallShield world where we have these big monolithic setup.exe type things and we are looking to make our installs more flexible and open the door to electronic distribution. It's an exciting vision and we're pumped to be working to make it happen.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
I've talked to the p2 team off an on over the last while trying to get a sense of what they were doing. But it really took Pascal's p2 long talk for it to really hit me. p2 is the new Update Manager (duh, that's what they've been saying all along). But as I look under the hood, it's an Update Manager on steroids (good thing there's no drug testing of software). And it's really got us excited.
The beauty of it is the extensibility. The underlying concepts are sound and based on some pretty standard notions albeit with weird names. InstallableUnits and Artifacts, what's the difference? Once you get past that you're fine. But the fact that you can override how things are installed with Touchpoints, and the fact that you can override how the Repositories are stored opens the door to some really exciting opportunities.
Aside from my internal work, I am looking to make a p2 based installer for Wascana. Yes, it can be used to install the Eclipse bits for the Platform, CDT and other plug-ins I need. But it should also be possible to use it to install the toolchain and libraries as well. What also struck me is that I should also be able to install the bits directly from their own download sites. This will allow me to quickly make available new releases of the components. The flexibility will still allow me to create off-line installs as well.
Another thing that popped into my head was whether p2 could be adapted to install Linux packages. Every distribution pretty much has it's own package manager. It would be very interesting if we could get p2 to install RPMs for example allowing us to use the same UI to set up Eclipse as well as packages, or even allow us to set up dependencies between them. Then we could create a Linux toolchain integration plug-in that depends on the compilers and have the p2 installer install the whole thing.
So as you can see I have big dreams for p2, probably more than the p2 team can handle at the moment. But it's an area that I really want to get involved in and contribute. And we'll see where we end up.
Monday, March 24, 2008
The community gets it
I just read Mike Milinkovich's post and it summarizes really well what Eclipse is all about. I'm going to use it as a reference whenever someone asks. And I'm going to add Cory Doctorow's quote to my list of mantras. "Ideas are cheap. Execution is hard". How true is that!
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
I often hear people wonder why the Eclipse Foundation staff doesn't step in and "fix" all of our conflicts. Well, that's not their job. That's not what Eclipse is all about. The Foundation is there to provide an environment that (hopefully) enables communities to succeed. They are facilitators. No, if there are conflicts happening it really is up to the community itself to do the heavy lifting to resolve those conflicts. And if there are projects that are dying, or suffering from a lack of diversity, it is up to the community to step in and fix it.
And the great news is that I really saw last week at EcilpseCon in the many discussions I had with members of the community, they get it. One guy asked me and I have no idea who he was, "so is AGR really dead"? I said, "yeah, as far as I know". Then he said back, "even if I try to contribute to it?" Wow. He gets it.
I passed Mike in the bar and he was talking to some of the guys and he was noticing that there were many more conversations happening in the hallways than in previous years. I have first hand experience at that. And I really think it's because the community is coming to EclipseCon to work. In previous years, many were coming just to see what was going on, maybe see what fancy new projects people were working on that they could use. I'm not saying that they are now coming to see how they can contribute. But they are realizing that if there's something that needs done, they have the power to step in and help make it happen. And that's an exciting trend.
The area that still has me concerned though is with the Eclipse Platform and the new e4 initiative. And, maybe a surprise to some, my problem isn't with the Platform committers. They worked very hard last week to make me feel at home and to push me to contribute to the platform, especially with the flexible resource model that we have been working to resolve in the CDT. And for that I am truly grateful.
No, my problem was with some of the questions and "ideas" that came up from the audience at the e4 BOF. We have been blessed with the Platform team's great work at providing us with a technology base that has enabled this rich community to grow. So much so that we've grown accustomed to receiving gifts of new features and fixes on a regular basis. That's got to stop. The feeling that I brought home with me is exactly what I had hoped. The Eclipse project is the same as any other project and needs to be treated as so. "Ideas are cheap. Execution is hard." If we as a community need things from the platform, it is up to us to do the heavy lifting to make change happen. We do have the power if we do the hard work necessary to make it happen.
Subscribe to:
Posts (Atom)