I believe in naming names and credit and blame where they are due.
I believe in accountability, even in FOSS.
An interesting (though very research intensive) article would
compare many open source projects and how well they meet their
The answer would be none of them [TM], except maybe Ubuntu and GNOME.
Most project have difficulty meeting their deadlines due to their voluntary work nature and the nature of developing software.
Software is a bit like 'OK if everything goes to plan, this should work' but no matter how much careful designing you did, there will always be one really really really annoying bug and obscure bug that will come up before release, usually as the result of a typo or something similar. (Think > instead of < in an if statement, which can lead to hard lockups due to infinite while loops).
Commercial organizations will either push the release back if there are a lot of showstopping bugs or they'll ask programmers to do what they can which usually results in a bunch of really nasty hacks before release.
Couple the nature of software development in general with the fact that a lot of developers do development because it is voluntary and they are in the mood usually leads to pushed back release dates. It's why giving an ETA for such things is never a good idea since it puts unnecessary pressure on you to get it done in a rush.
I always think you have to be in the mood to get some software hacking done. You're either feeling up to it or your aren't. It's weird. When you don't treat it like a chore, you'll get loads done in an instant, then move on to something else and come back to it later and get loads more done. If you treat it like a chore, nothing actually gets done.
Because C++ sucks and I wish it would die. It's too bloated and slow compared to C, C-- and assembly. (Sorry, couldn't resist )
On topic now, does anyone care to predict how Compiz will fit in once Gnome 3 is out? With KDE and Gnome having their own compositors enabled by default, Compiz would be left in a pretty tight spot (personally, I don't think I'd bother installing it at all).
Also, is there any progress on vsync support? I think x developers were working on a new protocol to allow compositors to sync to the refresh rate - does anyone know what's the status of that and whether it will be adopted by Compiz?
0) Speed usually comes down to how you design your program and not what language you use. C++ is generally a bit slower since you have a lot of symbols and cruft but the instruction-set is quite fine-tuned now, so the only real overhead is the memory usage from loading the cruft you might not need. However, in 0.9.0, things are faster anyways since we can use C++ routines to replace a lot of the stuff we used to make the plugin system work (function call chains) with 'smart functions' that only get called when they are needed (instead of call-im not needed-next call etc)
1) KDE is being co-operative and allowing you to replace their compositor. GNOME for what I can see is going for an all-inclusive "Panel + DM + WM"-in-one combo (not sure about the DM bit, but that is what I have seen recently) which means that if you try to replace any one of them you lose all three of their functionalities. I think GNOME will realize this isn't a smart idea to begin with once the stability issues arise, but it does mean that when GNOME-Panel is dropped that launching Compiz within a GNOME session means you don't get the shell.
2) I don't care about compiz being used as a default or not. Projects are generally better with small, consistent and involved communities (rather than everyone in Ubuntu getting it and not caring about it)
3) I believe we will get that for free once its done. Although this whole VSync issue is NVIDIA's fault and not ours. It happens on every OpenGL app
0) Heh, I was joking. There was a recent flamewar that debated the use of C++ over any and all managed languages (they are too slow, yarr!), so I found the comment on "getting rid of C++" more than a little funny.
Outside of numeric calculations, I wouldn't expect C++ to cause an appreciable drop in speed on today's hardware.
3) I couldn't care less about nvidia's blob, but this is an issue that affects open source drivers, too. Phoronix ran an article a couple of months ago on the cause and the proposed solution - the xorg wiki holds the details of the proposal but I cannot seem to find the exact page.