Christophe Fergeau a écrit 1255 commentaires

Merde, j'ai cru taper linuxfr.org dans mon navigateur, et je me retrouve sur http://bugzilla.ximian.com(...)
Faut que j'arrête de boire moi.

Alors, en théorie pour du code C, tu dois pas voir de pb d'échange entre les diverses versions de gcc. Dans ton cas, pour tes fichiers crt1.o et crt0.o, je serais moins optimiste ;) Si la personne qui t'as filé les fichiers les a compilé avec gcc 3.3, pourquoi tu n'utilises pas gcc 3.3 toi aussi ? Vu qu'elle les a compilé, le compilateur nécessaire existe pour ton proc ;)

Les bogomips, ça c'est vraiment une valeur fiable et représentative de la puissance d'une machine... Sur une machine x86, c'est généralement la fréquence de la machine, ou bien 2x la fréquence de la machine...

Autant envoyer 3 gars chez le développeur avec une batte de baseball, ça coûte moins cher et prends moins de temps au moins.

l'avantage du closed source, c'est que les sources sont sur le disque du développeur et chez personne d'autre, donc si il fait gaffe, y a peu de chance pour que son code soit piqué pour être intégré dans un soft proprio ;)

Non, la bonne réponse c'aurait été d'utiliser la glib pour tout ça, et d'éviter au maximum les fonctions de la libc et tous les pbs qui peuvent se poser avec si tu fais pas gaffe...

ma_struct = g_new0 (sizeof (struct MaStruct), 1);
ma_struct->chaine1 = g_strdup ("cequejeveux");
voire même
ma_struct->chaine2 = g_strdup_printf ("valeur: %u\n", un_entier);
etc, etc

Ca ressemble beaucoup aux fonctions de la libc, sauf que c'est portable (ok, strdup doit être portable aussi ;), mais surtout, les fonctions sont beaucoup plus robustes à mon avis... (genre elles renvoient toujours des chaînes terminées par des \0, la plupart du temps on te renvoie une copie, ..)

Et tu leur as écrit pour leur dire qu'ils avaient fait une erreur ? Toi si tu remplis une base de données de qques milliers d'applis, tu vas la remplir en ne faisant _aucune_ faute ?

> ben disons qu'en regle general dans le logiciel libre, une date de sortie est juste un point de repere pour savoir a peu pres quand ca va sortir; contrairement au logiciel proprio qui, vu les pressions/obligations commerciales, sort a la date annoncée !

Bah pas pour gnome en tout cas, y a un planning et on s'y tient.

> (à une instruction près, qui ressemble à un oubli d'AMD)

T'as plus d'infos sur cette différence/cet oubli ?

> Ca fait exactement la meme chose, sauf que en plus, ca s'interface a HAL

HAL utilise DBus pour envoyer des infos sur le bus au sujet des périphériques, DBus n'a aucune connaissance de HAL.

> En revanche, la gestion de la queue de l'imprimante est fait directement par cups il me semble, et je suis surpris de voir qu'il faut HAL + DBUS pour faire ca .

La partie HAL, ca doit surtout pour rendre l'installation de nouvelles imprimantes plus faciles. DBus est il me semble nécessaire pour pouvoir envoyer des messages au sujet des travaux d'impression aux applis qui sont intéressées (genre pour afficher la file des travaux d'impression dans la zone de notification ou trucs du genre). Tu vas me dire que c'est possible avec cups, mais il me semble qu'il faut alors faire du polling, ce qui est pas génial...

> C'est pas comme gstreamer par exemple. Quand on voit la stabilité d'un app comme rhythmbox ça plante une fois toutes les demi-heure

N° du bug que tu as ouvert avec la backtrace qui va bien sur bugzilla.gnome.org ?

Sinon, pour la petite histoire, GStreamer n'a pas été crée par des personnes de GNOME, et à ma connaissance le but initial de GStreamer n'était pas l'écriture d'un framework multimédia pour GNOME...

J'avais fait des recherches à une époque, et c'est effectivement peu supporté par les drivers actuels. Je me demande si j'avais pas lu que c'était pas possible avec l'implémentation actuelle de xrandr dans xfree d'ailleurs.
J'avais quand même fini par réussir à avoir une rotation en utilisant des options spécifiques aux drivers de la carte graphique (c'étiat une matrox g400 si je me souviens bien).

En cherchant un peu, tu dois pouvoir trouver un bench qui t'explique que le g4 en question qui est 2 fois plus lent que le g5 était beaucoup plus rapide qu'un super pentium de la mort qui tue, donc au final, t'obtiens une différence tellement hallucinante entre le p4 et le g5 que le bench en devient ridicule.

> Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.

Pas vraiment, pour gtk+ les bindings sont parfois générés automatiquement, parfois écrits à la main.

Accessoirement, le framework objet gobject a été pensé avec les bindings vers d'autres langages en tête, par ex lors de la destruction d'un objet, il y a deux "callbacks" différents qui sont appelés, ce mécanisme est essentiellement là parce que c'est utile à certains langages utilisant des garbage collectors.

> La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.

Ce qui est bien, c'est qu'encore une fois on peut utiliser cet argument pour expliquer que le C++ c'est nul comme langage, et que le C# serait plus adapté (je pense essentiellement aux possibilités d'introspection du C#)

Y a eu des débats au sujet de ce linux registry sur la mailing list de freedesktop.org y a qques mois, voir http://freedesktop.org/pipermail/xdg/2004-April/003753.html(...) et le thread qui s'ensuit par exemple.
En gros, linux registry n'est pas approprié pour être utilisé tel quel dans un desktop environment, et en ce qui concerne tous les démons systèmes, il apporte si peu d'avantages (voire même aucun) que c'est pas super intéressant de se prendre la tête à migrer tous les fichiers de config de tous les démons (apache, postfix, ...) vers ce système...
En bref, y a guère que l'auteur de ce linux registry et qques autres personnes qui sont convaincues que c'est un projet intéressant pour le monde du libre.

A mes yeux, avoir un gconf qui utiliserait par exemple dbus pour la communication entre le démon et les applis et serait utilisé par toutes les applis "desktop" (ie adopté par kde, rox, ...) est autrement plus intéressant

> Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.

A l'époque, une des raisons du choix du C devait être le fait que c'était le seul langage pour lequel il existait des compilateurs fonctionnant parfaitement (ou presque) sur toutes les plateformes, à l'époque, pour faire du C++ portable, fallait en gros se limiter aux fonctionnalités "simples" du langage. Ensuite, quand tu prends en compte que le c++ ne fournit pas toutes les fonctionnalités voulues, et qu'il y a un certain nombre de subtilités un peu chiantes à saisir, le choix du C peut se comprendre.

> Je pensais a gobject

Même dans le cas des gobjects, je ne pense pas qu'il y ait de vraies différences de perf, à part peut être à la création des objets, mais j'ai le sentiment que cette création est plus flexible qu'en C++ (mais je ne connais pas trop le C++...)

> Un naif qui s'est fait avoir.

Où plutôt un employé de RedHat à qui Havoc et Owen ont demandé de faire du code "nu" pour faciliter l'adoption

> Comme ca, pas de problemes de dependance.

Et de gros problèmes de maintenances en cas de grosse faille de sécu à boucher rapidement... (enfin la glib n'est probablement pas une lib critique de ce point de vue là)

Mon "mal foutu" faisait surtout référence aux fonctions du genre strndup qui se comportent bizarrement dans les cas pathologiques. Et gcc ne te prévient pas dans ces cas là

> C'est rudimentaire, mais c'est normal.

s/rudimentaire/mal foutu ? ;)
Y a pas mal de fonctions "dangereuses" (ie qui se favorisent les buffer overflow si tu fais pas gaffe aux cas particuliers), sans parler des pbs de portabilité. La glib résoud ces 2 problèmes. Donc c'est faux de dire que la libc n'a pas de fonctions de manipulations de chaine, mais je suis quand meme bien content d'avoir les fonctions fournies par la glib

Bon, on va passer sur la confusion glib/gobject, vu que les deux viennent dans la même tarball même si au final on a deux libs distinctes. La glib, c'est un ensemble de fonctions indispensables pour écrire un prog en C sans trop se prendre la tête (gestion de listes, de hash table, de chaines de caractères, ...), la couche C objet est totalement implémentée dans gobject, et la glib n'utilise pas du tout gobject.

> Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?

le C++ gère les signaux et les "properties" ? Non ? Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?

> quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?

Ca doit être chaud à trouver un système sans glib de nos jours ;) Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions ». Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...

> Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder

Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...

> Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.

Si tu parles de gobject, je comprends ton point de vue, si tu parles de la glib (en excluant la partie C objet donc), faudrait arrêter de fumer la moquette :) C'est criminel aujourd'hui de forcer qqu'un à écrire un truc en C sans utiliser une implémentation de list, de hash table, ... toute faite. Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser, ou bien dbus pour des exemples de mecs qui se font vraiment chier à faire du C sans glib ou assimilé pour faire plaisir à qques extrémistes kdeiens...
Sinon QT n'est comparable ni à la glib, ni aux gobjects jusqu'au jour où QT sera splitté en plusieurs libs...

Par contre, il devriat être posible d'écrire un serveur de son remplaçant d'esd en utilisant GStreamer ;)

oui "on top"
A ce moment là linux supporte xaml, avalon et tout ça depuis super longtemps parce que ces technos sont construites "on top of xml and http and ..." ?

Accessoirement, ces streams sont réalisé par des gars de chez fluendo (fluendo.com) à l'aide d'un serveur de streaming qui utilise gstreamer ;)

>. Mais DCOP est un protocole qui a fait ses preuves depuis 10 ans dans X et 5 ans dans KDE

C'est pas un truc qui a été inventé par KDE DCOP ?

> Chuis pas trop d'accord:
http://developer.gnome.org/doc/API/2.0/glib/glib-String-Chunks.html(...))

En lisant rapidement l'API, ça ressemble à un espace de stockage optimisé pour des chaînes (ie qqchose qui vise à remplacer malloc) plutôt qu'une vraie structure de donnée comme une liste ou une table de hachage. D'ailleurs, vu la gueule de l'api, il faut forcément qqchose à côté pour pouvoir utiliser les chaînes que tu as rangées dans ton string chunk.

> pour gstreamer, c'est moins violent, mais le probleme se pose quand meme des la premiere string que tu veux echanger entre kde et gstreamer

Oui bien sûr, mais tu n'as pas tant de conversions que ça à faire, et les conversions à faire ne sont probablement dans des branches critiques en temps d'exécution de ton code... De toute façon, une lib qui s'attend à recevoir une chaîne en UTF-8 fera un g_utf8_validate dessus avant de l'utiliser la plupart du temps, et c'est à mon avis à peu près aussi coûteux qu'une conversion d'un encodage dans un autre...

Pour la lib de correction orthographique, ca a clairement un coût, reste à voir si ce coût est vraiment rédhibitoire (orth ?), ie si ça apparaît dans le profiling lors de l'exécution...

>Une connerie a mon avis, vu que sur un 'char *' tu as plus de doute sur la nature de l'encodage utilise justement.

Il me semble qu'un GString, c'est tout bêtement une structure avec un char* et un gint (pour la longueur) dedans, ie il y a aucune notion d'encodage dans le GString non plus.
De toute façon, c'est simple, tout est en UTF-8, donc tu te poses pas de question ;)
Il n'y a pas de structure de donnée liste de string en gtk+ par contre, je vois pas trop l'intérêt par rapport à une glist à vrai dire...

Enfin ton argument sur le coût de conversion est un peu fallacieux, j'ai beau chercher, je ne vois pas tant de fonction utiles qui prendraient ou renverraient des listes/hash tables de string... (à part des listes de tag dans GStreamer).