When you're an Eclipse developer like I am who is taking advantage of Eclipse's cross-platform capabilities, you need to have a bunch of platforms to test your work on. The incredible growth of virtualization on the desktop over recent years has been a huge help for us who don't necessarily want their offices filled with a dozen machines.
I've tried them all and settled on VirtualBox, which was recently bought by Sun, as my Windows Laptop solution (I use KVM on my Linux desktop box). It has the best handling of screen resizing I've seen and thanks to the great support for this in recent Linux distros, the window for the VM flows nicely into my daily workflow.
VirtualBox released their 2.0 version last week. The big news is support for 64-bit hosts and guests (yeah, old news for other solutions, especially given VirtualBox still doesn't support SMP :( ). But what caught my eye was that extra download labeled 'SDK'. Nothing get's me more excited than an extensible platform (well, there are some things...). So I was quick to unwrap their new gift.
The SDK mainly covers APIs they've exposed to build VM management tools, similar to libvirt that's used on Linux platforms. It lets you create, configure, and launch VMs. Cool, and maybe it'll lead to better UIs for this, mind you the one they have is already pretty good.
The more interesting part of this was the last chapter of the SDKRef PDF file. It talks about the mechanism they use to allow communication between the guest operating system and the host. It allows you to create your own drivers that communicate through a virtual PCI device to a shared library on the host. Now the header files weren't shipped as part of the SDK, but they are part of the open source parts of VirtualBox. At least the doc shows you how. Very cool.
Now this comes to one of the most pressing things I wished virtualization could do, use the 3D graphic chips on the host. If I want to experiment with some of the ideas I have for 3D Linux UI frameworks, and still use Windows for my day job, I need something like that. And with this capability opened up for us to use, I can quickly imagine how I could get OpenGL calls from a guest OS out through this mechanism to the host OpenGL libraries. And I guess I'm not alone. In the list of built-in users of this mechanism is a mysterious service called VBoxSharedOpenGL.
Saturday, September 13, 2008
Wednesday, September 10, 2008
Time ripe for a Linux console?
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...
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...
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.
Subscribe to:
Posts (Atom)