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.
Saturday, June 28, 2008
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.
Subscribe to:
Posts (Atom)