GeneralZod a écrit 2316 commentaires

Différence de philosophie, c'est bien vite.
Gtk+ est un projet communautaire maintenu par des volontaires, Qt était un framework propriétaire qui s'est progressivement ouvert mais qui est très largement maintenu par une seule société. Dès le départ, le modèle de développement/économique n'était pas le même (bazar vs cathédrale).
Oui, Nokia/Qt fait plus d'efforts que Gtk+ mais ils ont plus de moyens, ce n'est pas de la 'mauvaise volonté' de la part des développeurs Gtk+.


Dans ce fil, on donne l'impression que KDE fait des efforts pour s'intégrer dans un environnement GNOME et que ce n'est pas réciproque.
KDE != Qt, KDE est un simple "utilisateur" de Qt, KDE ne participe peu (ou pas) au développement de Qt (à l'exception de Phonon), KDE n'a rien à voir avec les efforts d'intégration mené par Nokia. Une application KDE ne s'intégrera pas mieux à GNOME qu'une application GNOME à KDE, par défaut une application KDE n'utilise pas le thème par défaut de Gtk+ (donc pas de QGtkStyle).
Hormis le look, une application Qt n'est pas mieux intégré dans un environnement KDE que dans un environnement GNOME. Quant au feel d'une application Qt "vanilla", sans travail d'intégration, il sera tout aussi étranger sur bureau KDE que sur GNOME.

Si on commence à regarder sur FreeDesktop, on constate que GNOME fait beaucoup plus d'efforts que KDE pour favoriser l'interopérabilité en étant force de proposition, en implémentant les specs de façon la plus neutre possible (dbus, xdg, *Kit, etc...).
Qt fasse plus d'efforts certes, mais KDE bof bof.

Faut relativiser, derrière Qt, il y a une société (d'une taille fort respectable), des développeurs/testeurs/écrivains techniques à temps pleins etc ... En comparaison, Gtk+ est bien plus mal loti, la majorité des développeurs Gtk+ sont des développeurs GNOME.
Très peu de personnes sont payés pour travailler à temps plein sur Gtk+ (à ma connaissance, aucun actuellement).

QGtkStyle a été écrit courant 2008 et intégré dans Qt 4.5 (printemps 2009), c'est relativement récent l'intégration visuelle digne de ce nom dans un environnement basé Gtk+.
Puis, il manque pas mal de choses pour qu'une application Qt s'intégre parfaitement, par exemple, pouvoir utiliser les jeux d'icônes standard (c'est prévu pour Qt 4.7 il me semble), la disposition des labels dans les menus etc ...
Certes, de gros efforts ont été mené pour faciliter l'intégration de Qt dans les bureaux natifs (pas que GNOME, mais également Windows et OS X) mais principalement de la part de Nokia/Qt, pas des développeurs KDE (non affilié à Nokia s'entends).

C'est un peu trop facile de taper sur un Gtk+ qui est très loin d'avoir les mêmes ressources que Qt.

----

Pour revenir sur le sujet du journal, j'ai l'impression qu'on n'a pas compris l'objectif de Jonathan Thelin. D'abord Jonathan Thelin est un expert Qt reconnu (auteur du tutoriel indépendant de Qt, du bouquin "Foundations of Qt Development" *LE* meilleur bouquin d'initiation à Qt) et spécialiste de l'embarqué.
C'est avant tout une expérimentation, pas un projet bien défini. Plutôt que de permettre l'intégration des application Gtk+ à un environnement Qt (pas très réaliste, un moteur de rendu à gtk-qt-engine aurait plus approprié), ce serait surtout un kit de transition pour porter des applications Gtk+ vers un environnement Qt (sans Gtk+, sans X11 etc ...).
L'un des axes de développement de Qt est l'embarqué notamment la téléphonie mobile, entre Maemo qui va passer d'un environnement basé sur GNOME Mobile vers un environnement basé sur Qt.
J'ai bien souligné que Jonathan Thelin était un spécialiste de l'embarqué, maintenant à vous d'en tirer les conclusions sur l'intérêt de cette expérimentation.

> Étudiant, j'ai cotisé à la FSF, je n'ai jamais été mis au courant de cela ou du moindre vote.
Les associates members n'ont pas le droit de vote (c'est précisé sur la page).

> La FSF a énormément de pouvoir sur les projets GNU
ça dépends des projets, comme tu l'as toi-même souligné, la FSF n'a aucun contrôle sur un projet tel quel GNOME (qui *est* un projet GNU à l'origine et l'est encore). Quant au problème Ulrich Drepper, la résolution a été reporté ad vitam eternam, pourtant la GNU libc est un projet central au sein de GNU.
L'influence de la FSF sur les projets est à relativiser, même si il y aura probablement un rappel à l'ordre, ça n'empêche de travailler sur/utiliser Mailman avec un environnement orthodoxe.

> Aux dernières nouvelles RMS n'est pas un abruti fini
C'est pas évident à discerner après lecture de ce journal.

Primo, RMS n'est pas le dictateur à vie de la FSF, la FSF a une direction collégiale élue.
Secundo, un projet GNU, c'est un projet qui assigne son copyright à la FSF et/ou qui dispose de son aval. La marge de manoeuvre de la FSF ou de RMS dans la direction du projet est plus ou moins large, inexistante dans certains (GNOME qui est officiellement un projet GNU), lié à la plus ou moins bonne volonté du mainteneur (GNU libc), diluée (GCC) ou bien très présente (Emacs), etc ...
Hein, si tout les projets GNU écoutaient à la lettre RMS, ils seraient tous hébergé sur savannah, utiliseraient tous bzr comme vcs, etc ... Donc le wiki sapusaipalibre de Mailman, je ne crois pas que ce soit du ressort de RMS, et si il est au courant, je doute qu'il approuve.


Vendredi, vendredi, c'est vite dit.

Il y a eu un Google SOC l'année dernière et c'est prévu pour être intégré dans la prochaine version de KDE.
http://www.youtube.com/watch?v=i2rjiHEgoII
http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan

Pour les autres, il y a une discussion à ce sujet pour Mutter (la base de gnome-shell) l'été dernier mais pas de nouvelles depuis.

... que nos gouvernants copinent trop rapidement avec Microsoft.
http://linuxfr.org/~RedFox/28881.html
C'est plus l'absence de méfiance vis à vis de Microsoft que la (sur)méfiance envers Google qui me surprends.

Merde, mes balises troll ont été mangés ! :o

SongBird n'est pas un projet chapeauté par la Mozilla Foundation déjà qu'on n'est pas certain que Thunderbird le soit encore mais issu de la société "Pioneers of The Inevitable".
http://getsongbird.com/about/

La décision de Landley de passer en GPLv2 était stupide mais pas illégale.
BusyBox étant sous GPLv2+, rien ne t'interdit de distribuer l'ensemble sous GPLv2, mais les fichiers sous GPLv2+ reste individuellement sous cette licence. C'est exactement pareil avec le code BSD inclus dans les projets GPL.
D'ailleurs Bruce Perens n'a jamais contesté le droit de passer à GPLv2 à Landley, il lui a demandé d'attendre la finalisation de la GPLv3 avant de prendre sa décision (et la suite lui a donné raison).
Ce n'est qu'après échauffement de la discussion qu'il a exigé que son code reste sous GPLv2+ (et par conséquent BusyBox).

> surtout que leur analyse des droits de Perens est en grande partie bidon.
C'est surtout Perens qui estime que sa contribution a été minorée (ce qui reste à prouver), depuis 1996, le code de BusyBox a été réécrit plusieurs fois. C'est remarquable que du code à Perens se retrouve encore dedans à l'heure actuelle surtout après la polémique avec Landley.

Rob Landley a abandonné sa participation aux poursuites et s'en explique sur son "blog".
http://landley.net/notes.html

Il est intéressant de voir que son avis converge avec Bruce Perens, il y a un emballement de la part de la SFLC (d'après Landley) à poursuivre en justice toute société utilisant ou ayant utilisé du code provenant de BusyBox sans en respecter la licence, mis à part Andersen, plus personne lié de près ou de loin à BusyBox n'est associé aux poursuites.
Le cas de Cisco évoqué dans le billet est inquiétant, ça plonge un doute dans l'utilité et le bien-fondé de ces poursuites.

En résumé, Rob Landley et quelques développeurs se sont montés le bourrichon autour des drafts de la GPLv3. Voici la fameuse discussion dont parle Rob Landley
http://lists.busybox.net/pipermail/busybox/2006-September/05(...)
Comme à son habitude, Rob Landley a trollé sur la GPLv3 et a prétendu que BusyBox a toujours été sous GPLv2 only.
Bruce Perens est intervenu pour deux raisons :
* clarifier les choses, la licence originale est la GPL sans restriction pour les versions futures.
* demander à Rob Landley d'avoir l'amabilité d'attendre la finalisation de la GPLv3 et ce pour ne pas discréditer le travail de la FSF. Ironiquement, Rob Landley et les autres s'appuient volontiers sur la SFLC (co-rédactrice de la GPLv3) pour faire respecter leurs droits.
Après la conversation s'échauffe, Bruce Perens demande à ce que ses contributions demeurent sous GPLv2+ ==> d'où la dé-bruce-ification de BusyBox.
La mauvaise foi de Landley est évidente tout au long de la discussion.


La plupart des "craintes" des mainteneurs de BusyBox se sont révélés infondés, un exemple frappant où Rob Landley s'excite sur un point d'un draft de la GPLv3
http://lists.busybox.net/pipermail/busybox/2006-January/0520(...)
Et à propos des travaux dérivés, on trouve dans la version finale
If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
La FSF a bien pris en compte les remarques des développeurs de BusyBox (et d'autres) mais BusyBox a sauté le pas vers la GPLv2 only, un an avant.


Apparemment, la polémique serait une histoire de gros sous et de rancunes personnelles, Landley et Andersen ont touché un joli pactole lors des derniers procès. Et Bruce Perens ne serait pas le seul à vouloir sa part du gateau.

Effectivement, il a probablement atteint les limites d'une écriture bufferisée, donc la solution serait effectivement de passer à un noyau temps-réel ou de repenser les I/O.

Même si un noyau patché PREEMPT-RT n'est pas un noyau temps-réel à strictement parler (on parle plutôt de qualité de service), même fortement stressé, on arrive à des latences max de moins de 10 ms. L'avantage par rapport à un vrai noyau temps-réel comme Xenomai, c'est que c'est assez simple à mettre en oeuvre, et ça demande peu de modifications pour un bon programme.
http://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-appli(...)

Pour optimiser les I/O, quelques pistes :
* écriture vectorisé (writev) : ça permet au noyau d'optimiser les I/O, les opérations sont atomiques, en général ça pulse bien. C'est une technique souvent utilisée dans la vision industrielle.
* écriture asynchrone (man aio.h) : ça revient plus ou moins à l'idée de Christophe d'une gestion concurrente des écritures sans l'overhead lié à la gestion des threads. Un excellent article sur la question :
http://www.ibm.com/developerworks/linux/library/l-async/?ca=(...)

Bruce Perens n'a pas contribué à Busybox depuis plus d'une décennie, et a gardé le silence radio pendant longtemps.
Sa dernière intervention a été contre le changement de la licence de BusyBox de la GPLv2+ vers la GPLv2. Malheureusement pour lui, il est arrivé très tard dans la discussion, son inactivité dans le projet et son insistance n'ont pas joué en sa faveur.
Cet incident a incité les mainteneurs actuels à De-bruce-ifier le code de BusyBox (normalement, il doit rester

Il justifie son intervention sur le fait que la version de BusyBox incriminé (0.60.3) est basé principalement sur son travail (0.25).
En greppant les sources de la 0.60.3 et de la dernière version 1.15.3, on trouve
- 0.60.3 ==> 25 fichiers mentionnant Bruce Perens (dont 8 n'étant pas du code) sur un total de 303 fichiers. Ce qui au grand maximum représente 8.25 % de Busybox.
- 1.15.3 ==> 9 fichiers mentionnant Bruce Perens (dont un incertain) sur un total de 1619 fichiers soit pas plus de 0.6%.

Bruce Perens n'a vraisemblablement plus son mot à dire sur le développement actuel de BusyBox.
Néanmoins, ça ne décrédibilise pas totalement son intervention, une portion significative de BusyBox 0.60.3 reste de son fait, et seule une étude poussée du code de la version 0.60.3 pourrait confirmer son affirmation qu'une autre partie significative proviendrait des mainteneurs entre la période Perens et la période Andersen (non contactés également).

Pas mal l'astuce, je la note dans un coin. Je t'avoue que j'ai cru à une erreur de frappe.

Bien vu, mais en SQLite, ça donne :
SELECT *
FROM test
WHERE colonnes1 || colonne2 IN ('a|'|'b', 'c'||'d');
Pas de concat non plus chez Postgres, c'est une extension Oracle je crois.

mais ça ne répond toujours pas à la problématique, l'opérateur || fait une bête concaténation de chaine ce qui entraine des effets de bords. Un exemple, supposons que j'ai une table listant des personnes et que je cherche ceux qui répondent au nom de Micheline Battan.
Avec une requête utilisant l'opérateur de concaténation, tu vas tomber sur:
* Micheline Battan
* Michel Inebattan
* Michelin Ebattan
etc ... donc ça ne répond pas à la problématique donnée.

arf, j'ai oublié de préciser que l'exemple ci-dessus était un exemple d'utilisation de l'opérateur IN avec SQLite mais qu'il ne donnait pas le résultat attendu par l'auteur du fil.

SQLite supporte l'opérateur IN mais celui-ci ne renvoie qu'une colonne (c'est pareil avec Postgres). Je soupçonne ta requête d'utiliser un dialecte propre à MySQL.
SELECT *
FROM test
WHERE colonne1 IN('a', 'b')
AND colonne2 IN ('c', 'd'); ==> ça marche.

Maintenant, tout le monde connait la raison de l'abandon de KDE par les entreprises/distros, il n'existe pas assez d'argent sur Terre pour construire une machine KDE-ready !

> Ce qui me laisse plus dubitatif au niveau simplicité, c’est l’implémentation de tee_device.
Voici comment faire sans bibliothèque extérieure.

#include
#include
#include

class TeeBuf: public std::streambuf
{
public:
TeeBuf(std::streambuf * buf1, std::streambuf * buf2): buf1(buf1), buf2(buf2) {}
private:
int overflow(int c)
{
if (c == EOF) {
return !EOF;
} else {
return (EOF == buf1->sputc(c)) || (EOF == buf2->sputc(c)) ? EOF : c;
}
}
int sync()
{
return (0 == buf1->pubsync()) && (0 == buf2->pubsync()) ? 0 : -1;
}
private:
std::streambuf * buf1;
std::streambuf * buf2;
};

class TeeStream : public std::ostream
{
public:
TeeStream(std::ostream &o1, std::ostream &o2) : std::ostream(&buf), buf(o1.rdbuf(), o2.rdbuf()) {}
private:
TeeBuf buf;
};

int main()
{
using std::cout;
std::ofstream ofs("mon_fichier.txt");
/* avec TeeBuf */
std::streambuf *sortieLog = ofs.rdbuf();
std::streambuf *sortieStandard = cout.rdbuf();
TeeBuf *teeBuf = new TeeBuf(sortieStandard, sortieLog);
std::streambuf *oldBuf = cout.rdbuf(teeBuf);
cout<<"hello ";
cout.rdbuf(oldBuf);
/* avec TeeStream c'est un poil plus agréable */
TeeStream tee(cout, ofs);
tee<<"world!"<<std::endl;

ofs.close();
return 0;
}

> Et comme dit également plus haut, ce sont les méthodes standard de la librairie standard qui nous intéressent. Si la librairie standard n’est même pas fichue de faire des IO adaptables simplement, autant ne pas s’embêter à en fournir une.

Tu soulèves un dilemme qui touche tout les concepteurs de langages de programmation, quel doit être le contenu de la bibliothèque standard ?
C++ a fait le choix de fournir un système d'entrée/sortie souple et puissant (pas super compliqué) mais très rugueux, c'est un choix parmi d'autre.

> Je ne suis pas un développeur C++, juste un curieux, curieux de comprendre comment on peut appeler « supérieur » un système d’IO qui nécessite de connaître en profondeur les subtilités d’un langage réputé très complexe

Il est pas si complexe que ça, les IO Java sont bien plus tordues que ça à mon avis.
Si tu te limites à de l'affichage console, l'écriture dans des fichiers, c'est pas plus compliqué qu'avec les entrées/sorties C. Là, on s'attaque à un problème bien spécifique: i18n.
On peut s'attaquer aux entrées/sorties sans forcément devoir s'occuper des détails, std::string est également une spécialisation d'une classe templaté et ça ne pose pas de problèmes.

Enfin, si c'est pour faire du C en C++ sans utiliser les fonctionnalités avancés (stdio, pas de RAII, pas d'exception, pas de templates etc ..), autant faire du C.

> Est-ce la faute du langage ou du développeur si la base (les IO) de la base (la librairie standard) n’est pas simplement assimilable ?

Je dirais les deux, d'une part, C++ est un langage assez rugueux, de l'autre, C++ est très mal enseigné ce qui n'aide pas. Les concepteurs du langage en sont conscients (C++0x va dans ce sens) et cherchent à simplifier le langage.
C++ n'est clairement pas un langage adapté à des débutants en programmation, même si le dernier bouquin de Stroustrup (adaptation de son cours à des 1ères années de fac) démontre que c'est possible (une traduction est en cours aux éditions Pearson fr).
Dans le bouquin, il enseigne un style de programmation C++ moderne et n'aborde le sous-ensemble C du C++ que dans le dernier chapitre tout en restant accessible à tous.

Que ce soit en C ou en C++, si tu te limites à la bibliothèque standard, tu risques pas d'aller bien loin. Boost est aussi essentiel à un développeur C++, que Posix l'est à un développeur C.

> pour utiliser gettext avec ce magnifique système ?
Comme je l'ai précisé plus haut, les flux C++ sont des briques bas-niveau, rien ne t'interdit de construire un système de formattage par dessus. C'est ce que fait Boost.Format (avec des capacités supérieures à ce que propose C89/99), ou bien la classe autosprintf fourni par gettext qui en interne gère un flux C++. Tu bénéficies de la sûreté de typage tout en gardant les avantages du formatage.

> un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
À ce niveau là, la bibliothèque standard C et les flux C++ sont à égalité.
Certes le système des flux C++ est plus complexe à assimiler, mais une fois qu'on a compris, ça roule (Stroustrup a même fait un joli schéma). Pour ton exemple de tee, ça n'a rien de compliqué, il suffit de réécrire une classe héritant de std::streambuf qui redirige l'entrée vers plusieurs objets std::streambuf, et pour faire la redirection, tu utilises la méthode rdbuf pour faire la substitution. Tu peux écrire une classe héritant d'ostream pour avoir une interface plus agréable.
Boost.Iostreams facilite l'écriture de buffers, flux et filtres et fournit une collection d'objets prêt à l'emploi dont un tee.

ofstream ofs("mon_fichier.log");
tee_device<ostream, ofstream> teeDevice(cout, ofs);
stream teeStream(teeDevice);
teeStream << "comment faire un tee avec Boost, ne pas oublier de flusher le buffer !"<<std::endl;
teeStream.close();
Vachement compliqué à utiliser, non ?


Cette discussion confirme qu'une bonne partie des développeurs C++ ont une connaissance très partielle du langage y compris des bases (on parle quand même des entrées/sorties !).
Ça ne m'étonne guère, C++ en soi est ardu d'apprentissage, la plupart des formations enseigne un dialecte déprécié (le fameux C avec classes), les implémentations conformes à la norme se sont fait attendre longtemps etc...
Mais avant d'accuser C++ de tout les maux, faudrait peut-être l'apprendre correctement avant et choisir les bons outils. Aujourd'hui, un développeur C++ digne de ce nom doit être familier avec Boost ou du moins une bonne partie de Boost

Comme annoncé dans l'article, John Johansen est en train de pousser AppArmor dans le noyau, quand je parle du regain d'activité, je parle d'une tendance générale pas seulement de Linux 2.6.32.
D'après les logs de la branche linus, ce serait même la première contribution significative de Canonical au noyau si AppArmor est effectivement intégré.

La liste que tu as donnée ne se base pas sur l'adresse électronique pour identifier la provenance des commits. Par exemple, Kees Cook ingénieur sécurité de Canonical utilise son adresse personnel et quelques autres également.
Canonical connait réellement un regain d'activité au niveau du kernel, d'une part à cause d'AppArmor (dont ils sont l'upstream maintenant), d'autre part le développement de leur offre commerciale (serveur, OEM, etc ...). Le partenariat avec Google (ChromeOS) doit également influer, pour rappel, Intel a rompu le partenariat sur Moblin à cause des résultats décevants de Canonical dans le développement du support hardware (même si officiellement, une autre raison a été invoqué).

J'espère qu'ils continueront dans la bonne direction.

> ça donne l'impression que Canonical pousse que ça soit inclue dans le noyau et que le travail se fasse par autruie

Même si c'est la politique habituelle de la maison (1), sur ce coup-là, ils sont plutôt réglo. John Johansen a été embauché pour bosser spécifiquement sur AppArmor (et pas uniquement pour faire de l'intégration), et d'autres ingénieurs comme Steve Beattie (ancien d'Immunix), Kees Cook contribuent également. Le projet a d'ailleurs migré sur Launchpad.
https://edge.launchpad.net/~apparmor-dev
Reste que l'abandon d'AppArmor par Novell/Immunix a été un sacré coup dur au projet qui a peu évolué en deux ans. Je ne vois plus trop l'intérêt pour Canonical de perfuser AppArmor alors que SELinux est mature, activement maintenu, bien intégré et nettement plus robuste et complet.
http://www.linux-magazine.com/w3/issue/69/AppArmor_vs_SELinu(...)

(1) si vous voulez étriller Canonical, chercher du côté de X ou bien KVM, le décalage entre la propagande marketing et l'activité réelle est phénoménale. Mais ce n'est pas le sujet de la dépêche.

Comme souligné précédemment, lorsque tu fais cat *.c, le shell développe le motif en des noms de fichiers existants avant de le donner à manger à cat.
Pour obtenir un comportement similaire, tu peux utiliser la fonction C ISO fnmatch pour comparer les motifs (à charge pour toi de récupérer les noms de fichiers du répertoire courant), soit la fonction Posix tout-en-un glob.
Si tu cherches des détails sur le globbing (attention, ce ne sont pas des expressions régulières) ==> man 7 glob
La version 2001 de Posix offre également la fonction wordexp qui offre l'expansion du tilde et pleins d'autre chose (très pratique pour implémenter un mini shell).


Autre chose, pour gérer la redirection des flux standards, utilise plutôt dup2, ton code sera plus court et plus explicite.
dup2(fd,STDOUT_FILENO);
dup2(fd,STDERR_FILENO);

Le sujet d'origine c'est "cout c'est pourri, printf saimieu" ou autrement dit "pourquoi utiliser les flux C++ et non pas les entrées/sorties C en C++".
Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf

> Ça tombe bien, depuis le début du thread on parle de la syntaxe de printf, et non de son implémentation/conception.
Et juste en dessous, je précise que la bibliothèque D standard la plus utilisé (Tango) offre des entrées/sorties inspirées du C++ avec des capacités de formatage modernes comme ce qui se fait aujourd'hui.
La syntaxe printf est certes pratique mais dépassée, les syntaxes modernes permettent de réutiliser plusieurs fois le même argument, de modifier l'ordre des arguments etc ...


Si ça te chante, tu peux très bien faire ta propre fonction improved_printf qui gère son propre flux en interne. Les entrées/sorties C++ sont un poil plus bas-niveau que leur homologue C mais en contrepartie, elles sont plus sûres et extensibles. L'absence de fonctionnalités plus haut niveau dans le standard est regrettable mais ce n'est pas une raison valable pour préférer printf. Le problème des bibliothèques standards, c'est que tu ne peux pas tout inclure dedans et il vaut mieux réfléchir plusieurs fois avant d'inclure quelque chose dedans.
Et c'est oublier des extensions de la bibliothèque standard comme Boost (ou même POCO), ou bien ce que propose n'importe quel toolkit moderne comme Qt.