Allons, allons, on sait tous tres bien que c'est pas comme ca que ca fonctionne en realite.
La meilleure preuve c'est que ce comite technique evite a tout prix de se reunir pour discuter technique et ne demande l'avis de RMS qu'en dernier recours.
You're not completely right, and not completely wrong. The politics are exceedingly complicated, and I regret it every time I learn more about them.
RMS doesn't have dictatorial power over the SC, nor a formal veto vote.
He does hold the copyright to GCC. (Well, the FSF holds the copyright, but he is the FSF.) That's a lot more important that many people realize.
Choice of implementation language is, strictly speaking, a purely technical issue. But it has so many consequences that it gets special attention.
The SC specifically avoids getting involved in technical issues whenever possible. Even when the SC is asked to decide something, they never go to RMS when they can help it, because he's so unaware of modern real-world technical issues and the bigger picture. It's far, far better to continue postponing a question than to ask it, when RMS is involved, because he will make a snap decision based on his own bizarre technical ideas, and then never change his mind in time for the new decision to be worth anything.
He can be convinced. Eventually. It took the SC over a year to explain and demonstrate that Java bytecode could not easily be used to subvert the GPL, therefore permitting GCJ to be checked in to the official repository was okay. I'm sure that someday we'll be using C++ in core code. Just not anytime soon.
As for forking again... well, yeah, I personally happen to be a proponent of that path. But I'm keenly aware of the damange that would to do GCC's reputation -- beyond the short-sighted typical /. viewpoint of "always disobey every authority" -- and I'm still probably underestimating the problems.
C'etait en 2004. Ca a prix plus de 6 ans pour arriver a "convaincre" RMS d'avoir du C++ dans GCC.
Et bizarrement, tous les projets dans lesquels il est dans le comite decisionnel mais n'ecrit pas de code (genre Gnome, GlibC - pas emacs donc) ont le meme genre de probleme et preferent eviter d'avoir affaire a lui.
Il est tres bien comme representant du LL facon FSF, mais des qu'il s'agit de discuter technique, c'est plutot un frein aux projets sur lesquels il a de l'influence (et on parle pas de faire du proprio, juste d'eviter des decisions techniques debiles).
[^] # Re: To FUD or not to FUD
Posté par Littleboy . En réponse au journal Apple prépare-t'il un coup 'à la Oracle'?. Évalué à 9.
La meilleure preuve c'est que ce comite technique evite a tout prix de se reunir pour discuter technique et ne demande l'avis de RMS qu'en dernier recours.
http://developers.slashdot.org/comments.pl?sid=117940&ci(...)
You're not completely right, and not completely wrong. The politics are exceedingly complicated, and I regret it every time I learn more about them.
RMS doesn't have dictatorial power over the SC, nor a formal veto vote.
He does hold the copyright to GCC. (Well, the FSF holds the copyright, but he is the FSF.) That's a lot more important that many people realize.
Choice of implementation language is, strictly speaking, a purely technical issue. But it has so many consequences that it gets special attention.
The SC specifically avoids getting involved in technical issues whenever possible. Even when the SC is asked to decide something, they never go to RMS when they can help it, because he's so unaware of modern real-world technical issues and the bigger picture. It's far, far better to continue postponing a question than to ask it, when RMS is involved, because he will make a snap decision based on his own bizarre technical ideas, and then never change his mind in time for the new decision to be worth anything.
He can be convinced. Eventually. It took the SC over a year to explain and demonstrate that Java bytecode could not easily be used to subvert the GPL, therefore permitting GCJ to be checked in to the official repository was okay. I'm sure that someday we'll be using C++ in core code. Just not anytime soon.
As for forking again... well, yeah, I personally happen to be a proponent of that path. But I'm keenly aware of the damange that would to do GCC's reputation -- beyond the short-sighted typical /. viewpoint of "always disobey every authority" -- and I'm still probably underestimating the problems.
C'etait en 2004. Ca a prix plus de 6 ans pour arriver a "convaincre" RMS d'avoir du C++ dans GCC.
Et bizarrement, tous les projets dans lesquels il est dans le comite decisionnel mais n'ecrit pas de code (genre Gnome, GlibC - pas emacs donc) ont le meme genre de probleme et preferent eviter d'avoir affaire a lui.
Il est tres bien comme representant du LL facon FSF, mais des qu'il s'agit de discuter technique, c'est plutot un frein aux projets sur lesquels il a de l'influence (et on parle pas de faire du proprio, juste d'eviter des decisions techniques debiles).