> tu essaye de raisonner avec une explication litéraire.
Je fais de mon mieux pour parler français et pas la banlieu.
Alors ziva, lâche moi la grappe :-)
Sinon j'ai mon "micro robert" (pas très litéraire...).
Moderne :
1- Actuel, contemporain, récent
2- Qui bénéficie des progrès récents, correspond au goût actuel
3- (personnes) qui tient compte de l'évolution récente dans son domaine
Le 1 et le 2 me conviennent. Le 3 pour les personnes me convient aussi.
Unix tombe en 1 et Linux plutôt en 2.
Tu préfères ne retenir que le 2.
Le français étant une langue vivante, je ne vais pas te le reprocher.
> Je parlais bien de certaines situations : je fais de la sauvegarde et je suis régulièrement confronté à des clients qui ont des répertoires avec des millions de fichiers temporaires sur leurs serveurs.
Temporaires ?!?
Il y a un problème alors.
M'enfin, en gros avec les paramètres par défaut, il y a 1 inodes pour 2 à 3 blocks.
Le maxi est 1 inodes par block (pour reiserfs ça doit aussi être le cas).
Bref, il faut vraiment en vouloir pour atteindre la limite de la valeur par défaut.
Je ne dis pas que ça n'arrive pas. Mais ça doit être rare.
Rendre la taille de la table des inodes dynamique est dans la TODO list. Ça passera peut-être par par un "umount ... ; tune2fs ... ; e2fsck (peut-être) ; mount".
Dans /usr/src/linux-2.6.8-1.521/Documentation/ide.txt j'ai :
Summary of ide driver parameters for kernel command line
--------------------------------------------------------
(...)
"hdx=cdrom" : drive is present, and is a cdrom drive
(...)
Je n'ai pas de "hdx=ide-cd".
Si ça ne marche pas sans "hdc=ide-cd", essai avec "hdc=cdrom".
C'est tout le "charme" de la lib C. Pour des raisons de vitesse, il n'y a aucun contrôle. C'est à ton programme de contrôler ou voir qu'un contrôle n'est pas nécessaire et gagner en vitesse (ce type d'optimisation est à faire au compte-goute, c-à-d après un profile).
Par contre il y a des fonctions (ou des fonctions avec certains paramètres) qu'il faut éviter car là ton programme ne peut garantir que la fonction retournera...
Typiquement il y a gets() et (f)scanf().
Des solutions en restant avec la lib C existent mais c'est lourdingue (utiliser read() puis sscanf(), etc). Des extensions GNU fournissent des solutions fiables.
Bref, on sent rapidement tout l'intérêt d'avoir la glib sous le coude :-)
Pas d'accord. Ce n'est pas le rôle de la lib C ou de POSIX (pour la lib C :-)) d'avoir des fonctions de haut niveau.
La lib C offre le minimum pour tout faire. Ça fait bizarre comme phrase mais c'est le cas. D'ailleur il n'y a pas le choix, tout fini par passer par la libc avant de passer par le noyau.
Le but est la vitesse, la taille, la vitesse, la taille et la portabilité.
Pour les fonctions "dangereuses", c'est principalement pour des raisons historiques. Puis la libc GNU a la délicatesse de mettre un warning lorsqu'on utilise une fonction dangereuse et de vérifier les appels des fonctions à nombres de paramètres variables.
> sans parler des pbs de portabilité.
J'ai développé des programmes qui doivent tourner sur plusieurs Unix et c'est assez mineur (entre système Unix !). Il y a des difficultés beaucoup plus dure ailleur (make, le shell, l'édition de lien des librairies partager, etc).
Puis ces problèmes de portabilité sont les problèmes classiques de non respect de norme. D'ailleur tu peux aussi installer la lib C gnu si la lib C de l'OS (proprio forcément) t'emmerde.
Par contre, et on s'y attend, c'est beaucoup plus merdique avec Windows.
> je suis quand meme bien content d'avoir les fonctions fournies par la glib.
Moi aussi, et bien que je trouve la lib C bien foutu (compte tenu des objectifs/contraintes) je pousse tout le monde à utiliser Glib qui est beaucoup plus "confortable", sûre et portable.
PS :
J'invite à lire la doc de la libc (info libc) qui est l'un des meilleurs moyens pour faire connaissance avec Linux.
> l'abscence totale de toute fonction de manipulation de texte dans la libc
?
Par exemple :
man string.h
C'est dans la norme de la librairie C.
C'est rudimentaire, mais c'est normal.
Faire aussi :
info --node="String and Array Utilities" -f /usr/share/info/libc.info.gz
> Un programme peut legitimement refuser de dependre de la glib s'il ne depends pas de la libc
Les programmes qui ne dépendent pas de la libc doivent se compter dans sur les doigts d'une main. A ma connaissance :
- linux
- memtest86 ?
Tu as quoi comme paramètre de boot (dans grub.conf) ?
Il n'y a pas un "ide-scsi=/dev/hdc" ou "/dev/hdc=ide-scsi" ou ide-ignore (j'ai oublié la forme exacte) ?
A ce propos, il y a aussi une option de module de ide-cd équivalente à ide-ignore. Vérifies bien qu'il n'y a pas un truc dans ce goût qui traine.
Je sais que dans RH8.0 pour les graveurs, anaconda renvoie la gestion du lecteur à ide-scsi.
> Afin d'intégrer les fonctionnalités de chargement de module, j'avais plutôt mis à jour 'module-init-tools'
Tu as raison.
La confusion vient que module-init-tools est dans le paquet modutils sous Fedora Core 2 (Linux 2.6). En fait, ce paquet a modutils (l'ancien) et module-init-tools (le nouveau).
Pour Rawhide (version de développement de Fedora) le paquet se nomme module-init-tools (il y a que le nouveau).
OK, c'est bon.
- glib est un problème de performance pour utiliser Gstreamer dans KDE
- les bindings ça ne sert à rien
- KDE et ARTS n'ont rien à voir ou presque
- glib est une horreur pour faire des binding en C++
- Qt ne dépent pas X11 (aujourd'hui)
- J'emmerde toutes les développeurs KDE qui sont tous des crétins (fallait bien que je les insulte quelque part).
- etc...
> Je ne critiquais pas la possibilitée de faire des bindings, mais leur utilitées
Je ne sais pas ...
Par exemple utiliser gstreamer en C++.
Ou utiliser ce sympathique programme en python qui utilise Gnome : http://meld.sourceforge.net/(...)
Ou avoir yum qui utilise le binding python de rpm (qui est aussi utilisé par up2date, anaconda, etc).
Il faut mettre (pour être complet avec ide) :
alias block-major-3-* ide-probe-mod
alias block-major-22-* ide-probe-mod
alias block-major-33-* ide-probe-mod
alias block-major-34-* ide-probe-mod
alias block-major-56-* ide-probe-mod
alias block-major-57-* ide-probe-mod
alias block-major-88-* ide-probe-mod
alias block-major-89-* ide-probe-mod
alias block-major-90-* ide-probe-mod
alias block-major-91-* ide-probe-mod
modprobe a complètement changé entre 2.4 et 2.6.
Faut aussi mettre à jours modutils (et d'autres trucs mais j'ai oublié). Sinon ça ne marchera jamais.
D'accord. C'est comme ça que KDE a toujours une version d'avance sur les autres...
Ils sont présentement à la version suivante.
Pour vous le présent, c'est la version futur.
Je sais, je répète. J'ai (ou j'avais ?) un peu de mal avec le concept.
Rassures toi, ça ira (ou ça va ? le présent c'est le futur..), heu non..
Rassures toi ça va mieux demain. Heu non plus.
Très bien.
KDE ne supporte pas le son.
KDE n'a jamais eu de serveur de son.
C'est un add-on que les distribution ajoutent.
J'ignorais.
J'ai toujours du mal à comprend pourquoi kdelib en dépend...
Et pourquoi lorsque je fait "./configure --help | grep arts" dans les sources de kdelib (sans patch) j'ai :
--without-arts build without aRts default=no
Welcome to the KDE Multimedia site!
(...)
In KDE 2 and 3 these interfaces are largely built on the daemon and libraries of the Analog Real-Time Synthesizer, known as aRts.
(...)
These pages provide information on KDE multimedia and aRts.
C'est parque mon pétard n'était pas frais.
Maintenant tu peux faire comme Alex et dire que je suis bouché, et que je ne veux pas comprendre etc.
Non, ça je ne veux pas comprendre.
> Va sur le site de Arts, tu vera que ce n'est pas un projet Kde.
Vas sur le site de gtreamer, tu verras que ce n'est pas un projet Gnome.
Donc Gnome n'a aucune dépendance avec Gstreamer ?
Ben si, Gnome dépend de Gstreamer.
> tu sembles avoir du mal a comprendre qu'on puisse ne pas être daccord avec toi.
Faut être conhérent avec moi sinon je suis dure de l'oreille. Jusqu'à maintenant et après beaucoup de requêtes, j'ai _AUCUN_ exemple de plus "C++ friendly" que par exemple gstreamer avec glib.
Le seul argument, et il est récurrent, est :
- le C++ est plus "C++ friendly"
Tu m'étonnes... que je suis d'accord. Mais ce n'est en rien convaincant.
De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.
Le seul argument qui mérite un peu d'être vérifié est par rapport à openssl que je ne connait pas. Mais openssl n'a rien pour aider de façon générique les bindings en language objet.
> on crutique ton "C++ friendly" a propos de la glib
Ben critiquez mieux.
btw, ça revient à critiquer glib et dire que glib n'est pas "C++ friendly" et non seulement à critiquer mon "C++....
glib n'a peut-être pas été faite pour être spécifiquement "C++ friendly" mais elle a été fait pour être objet friendly. Les bindings en languages objets de gtk+ le prouve.
Le C++ à part être "C++ friendly" est assez limité dans ce domaine.
Parce c'est une lib métier.
glib ne sert à rien si j'ose dire...
> et sur quoi tu te bases pour "sentir" ça ?
La preuve, toi :
- "c'est un ajout de travail qui fait de plus doublon avec ce que déjà le C++"
- "je pense quand même que c'est une perte de temps vu ce qu'elle apporte par rapport a des framework C++"
En gros, la programmation objet si ce n'est pas en C++, c'est doublon ou moins bien et donc inutile.
Et puisqu'on est sur les bindings, il est beaucoup plus facile de faire des bindings si la librairie de base est en C qu'en C++.
Faire le binding d'une librairie C++ qui utilise tout les fonctionnalités C++ est pratiquement impossible (ou c'est immonde). Pour preuve, les bindings de librairies C++ sont rares ou alors se sont des bindings vers java ou C#.
Mouaifff...
Combiens de programme/lib kde utilisent arts ?
Tu peux aussi dire que KDE n'utilise pas libX11 ni la librairie C alors.
kdelib utilise arts.
> pas d'itérateur, pas d'héritage, pas de plein de chose qui font d'une api quelque chose de C++ friendly.
J'amais content.
Ben faites votre Kstreamer dans votre coin qui sera "nobody friendly" et arrêter de critiquer le boulot des autres car il n'est pas "KDE friendly" alors que vous avez une attitude hostile à tout.
> je pense qu'elle doit venir d'esound
esound n'utilise pas glib (que la libc et alsa).
C'est arts (KDE) qui utilise glib.
Trouves une lib (non C++ puisque Gtk+/Gnome est en C pour supporter le binding) qui est plus "C++ friendly". Un truc en Java ou C# ? Désolé mais c'est pas la même catégorie.
Le développeur KDE qui fait le wrap gstreamer trouve ça facile à réaliser.
J'ai vu plus bas : APR, NSPR (j'ignore volontairement openssl).
En quoi elles sont mieux ?
glib/apr/nspr ont toute été faite en même temps environ (à un an près. glib est plus vieille mais était au début intégrée à gtk+).
Il me semble peut probable de voir une nouvelle librairie de ce type.
Puis glib est nettement plus utilisée. Non que les autres soit de moins bonne qualité (je ne connait pas nspr). apr est "limité" à apache et subversion (qui utilise aussi apache) et nspr à mozilla.
Peuvent-elles supporter la programmation objet pour faire de "joli" binding C++ ?
Je sens qu'on va encore me répondre un truc du style "la programmation object est réservé aux élites du C++".
> > Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?
> le C++ gère les signaux et les "properties" ? Non ?
Je n'ai pas envis de rentrer dans le technique, mais ce qui m'énerve le plus dans "pourquoi ne pas faire du C++", c'est ce côté "la programmation object c'est pour C++ et pas pour les autres".
Le premier bouquin sur le C ("Le langage C" par Kernighan et Ritchie) indiquait qu'un bon programme était souvent orienté objet.
Suffit de regarder les sources de Linux pour détecter rapidement des parties orientées objets. Évidemment, ce n'est pas aussi luxueux que le C++ et on peut chipoter sur mon emploi de "orienté objet".
btw, faire de l'orienté objet avec du C est très vieux (libXt est un très bon exemple).
À la question "pouquoi faire de l'objet avec du C", je réponds :
- "Car la programmation objet c'est bien et le language C c'est bien."
> > si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi
Qt est GPL. L'objectif de Gnome est d'avoir des librairies LGPL.
Qt ne permet pas les bindings (ou ce n'est pas terrible à de très rare exception).
Qt est payant sous Windows.
Qt est C++, il faut donc compiler l'appli avec un compilateur C++ (Il y a des techniques pour éviter ce problème mais c'est particuliairement ugly).
Qt dépend de X11 (et de plein d'autre trucs) alors que glib ne dépend que de la libc. Idéal aussi pour un programme non graphique. Donc rien à voir.
> 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.
Absolument. Surtout que l'empreinte mémoire de glib (hors gobject) est ridicule. Et en fait n'est chargé en mémoire que ce qui est utilisé.
De plus la multiplication des implémentations de list, hash table ... fait que ça bouffe plus de mémoire que si tout le monde utilisait la glib.
Du gâchis en place mémoire et en temps de développement et pour faire plaisir à "qques extrémistes kdeiens..." comme tu le dis.
PS : glib est un lib vraiment bien foutu. Un must pour développeurs C et quelque soit le type d'appli (graphique ou non).
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
Je fais de mon mieux pour parler français et pas la banlieu.
Alors ziva, lâche moi la grappe :-)
Sinon j'ai mon "micro robert" (pas très litéraire...).
Moderne :
1- Actuel, contemporain, récent
2- Qui bénéficie des progrès récents, correspond au goût actuel
3- (personnes) qui tient compte de l'évolution récente dans son domaine
Le 1 et le 2 me conviennent. Le 3 pour les personnes me convient aussi.
Unix tombe en 1 et Linux plutôt en 2.
Tu préfères ne retenir que le 2.
Le français étant une langue vivante, je ne vais pas te le reprocher.
[^] # Re: Conseils ?
Posté par 007 . En réponse à la dépêche Sortie de la version 4 de ReiserFS. Évalué à 1.
Temporaires ?!?
Il y a un problème alors.
M'enfin, en gros avec les paramètres par défaut, il y a 1 inodes pour 2 à 3 blocks.
Le maxi est 1 inodes par block (pour reiserfs ça doit aussi être le cas).
Bref, il faut vraiment en vouloir pour atteindre la limite de la valeur par défaut.
Je ne dis pas que ça n'arrive pas. Mais ça doit être rare.
Rendre la taille de la table des inodes dynamique est dans la TODO list. Ça passera peut-être par par un "umount ... ; tune2fs ... ; e2fsck (peut-être) ; mount".
Pas de délais annoncé.
[^] # Re: Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
# modprobe ide-cd
Il détecte mon cdrom, voici le message :
# hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
J'ai retrouvé mon option ignore...
Exemple
rmmod ide_cd
modprobe ide_cd
kernel : hdb: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
kernel : hdd: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
rmmod ide_cd
echo "options ide-cd ignore=hdb" >> /etc/modprobe.conf
modprobe ide_cd
kernel : ignoring drive hdb
kernel : hdd: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
rmmod ide_cd
head /dev/hdb > /dev/null
head: Ne peut ouvrir `/dev/hdb' en lecture: Aucun périphérique ou adresse
kernel: ide-cd: ignoring drive hdb
hdd: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
Pas très utile dans ton cas :-)
A l'origine, ça évitait des problèmes si ide-scsi devait être utilisé et n'était pas déjà chargé.
[^] # Re: Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
Enlève "hdc=ide-cd"
Dans /usr/src/linux-2.6.8-1.521/Documentation/ide.txt j'ai :
Summary of ide driver parameters for kernel command line
--------------------------------------------------------
(...)
"hdx=cdrom" : drive is present, and is a cdrom drive
(...)
Je n'ai pas de "hdx=ide-cd".
Si ça ne marche pas sans "hdc=ide-cd", essai avec "hdc=cdrom".
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Ouais.
> genre strndup
C'est tout le "charme" de la lib C. Pour des raisons de vitesse, il n'y a aucun contrôle. C'est à ton programme de contrôler ou voir qu'un contrôle n'est pas nécessaire et gagner en vitesse (ce type d'optimisation est à faire au compte-goute, c-à-d après un profile).
Par contre il y a des fonctions (ou des fonctions avec certains paramètres) qu'il faut éviter car là ton programme ne peut garantir que la fonction retournera...
Typiquement il y a gets() et (f)scanf().
Des solutions en restant avec la lib C existent mais c'est lourdingue (utiliser read() puis sscanf(), etc). Des extensions GNU fournissent des solutions fiables.
Bref, on sent rapidement tout l'intérêt d'avoir la glib sous le coude :-)
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Pas d'accord. Ce n'est pas le rôle de la lib C ou de POSIX (pour la lib C :-)) d'avoir des fonctions de haut niveau.
La lib C offre le minimum pour tout faire. Ça fait bizarre comme phrase mais c'est le cas. D'ailleur il n'y a pas le choix, tout fini par passer par la libc avant de passer par le noyau.
Le but est la vitesse, la taille, la vitesse, la taille et la portabilité.
Pour les fonctions "dangereuses", c'est principalement pour des raisons historiques. Puis la libc GNU a la délicatesse de mettre un warning lorsqu'on utilise une fonction dangereuse et de vérifier les appels des fonctions à nombres de paramètres variables.
> sans parler des pbs de portabilité.
J'ai développé des programmes qui doivent tourner sur plusieurs Unix et c'est assez mineur (entre système Unix !). Il y a des difficultés beaucoup plus dure ailleur (make, le shell, l'édition de lien des librairies partager, etc).
Puis ces problèmes de portabilité sont les problèmes classiques de non respect de norme. D'ailleur tu peux aussi installer la lib C gnu si la lib C de l'OS (proprio forcément) t'emmerde.
Par contre, et on s'y attend, c'est beaucoup plus merdique avec Windows.
> je suis quand meme bien content d'avoir les fonctions fournies par la glib.
Moi aussi, et bien que je trouve la lib C bien foutu (compte tenu des objectifs/contraintes) je pousse tout le monde à utiliser Glib qui est beaucoup plus "confortable", sûre et portable.
PS :
J'invite à lire la doc de la libc (info libc) qui est l'un des meilleurs moyens pour faire connaissance avec Linux.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
?
Par exemple :
man string.h
C'est dans la norme de la librairie C.
C'est rudimentaire, mais c'est normal.
Faire aussi :
info --node="String and Array Utilities" -f /usr/share/info/libc.info.gz
> Un programme peut legitimement refuser de dependre de la glib s'il ne depends pas de la libc
Les programmes qui ne dépendent pas de la libc doivent se compter dans sur les doigts d'une main. A ma connaissance :
- linux
- memtest86 ?
[^] # Re: Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
Il n'y a pas un "ide-scsi=/dev/hdc" ou "/dev/hdc=ide-scsi" ou ide-ignore (j'ai oublié la forme exacte) ?
A ce propos, il y a aussi une option de module de ide-cd équivalente à ide-ignore. Vérifies bien qu'il n'y a pas un truc dans ce goût qui traine.
Je sais que dans RH8.0 pour les graveurs, anaconda renvoie la gestion du lecteur à ide-scsi.
[^] # Re: Gentoo ?
Posté par 007 . En réponse au message Quelle distrib ?. Évalué à 1.
Ben ça dépend.
Parfois c'est plus de 24 heures de compilation sans problème (athlon 1600 xp).
Exemple pour le 22/08 : http://fw07.dmacc.net/rawhide-reports/1ByqBv-0004vk-J8.html(...)
- gcc
- glibc
- kernel
- xorg
Et j'ai déjà vu rawhide recompilé à 80 % suite à un changement de compilateur.
Je te laisse imaginer le temps nécessaire pour tout recompiler.
Regardes comme ça bouge sur Rawhide :
http://fw07.dmacc.net/rawhide-reports/(...)
J'ai pas envis d'occuper ma bécane 6 à 12 h par jour en recompilation.
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par 007 . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Oui
> sur le bien fondé, ou non, de l'utilisation de pilotes binaires proprio sous linux.
Mouaifff...
Perso, quand ça cause de "code proprio de firmware" même si c'est vrai, ça sent le troll à plein nez.
Alan Cox utilise aussi des firmware proprio et j'espère que tu ne vas pas remettre en cause sont engagement pour le libre.
Et Alan Cox utilise aussi Google.
Le LL n'est pas une dictature.
[^] # Re: Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
C'est bien la chaine "ide-probe-mod" qu'il faut mettre !
Il ne faut pas remplacer "ide-probe-mod" par "ide-cd" par exemple.
Tout ça est dans /etc/modprobe.conf.dist qui est assez gros :
wc -l /etc/modprobe.conf.dist
160 /etc/modprobe.conf.dist
Pour récupérer le fichier :
# rpm -q -f /etc/modprobe.conf.dist
modutils-2.4.26-16
Suffit de prendre celui de FC2.
[^] # Re: Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
Tu as raison.
La confusion vient que module-init-tools est dans le paquet modutils sous Fedora Core 2 (Linux 2.6). En fait, ce paquet a modutils (l'ancien) et module-init-tools (le nouveau).
Pour Rawhide (version de développement de Fedora) le paquet se nomme module-init-tools (il y a que le nouveau).
> En effet, ce package contient 'kerneld'
kerneld n'existe plus depuis Linux 2.4 je crois.
Il y a des paquets pour avoir Linux 2.6 :
http://people.redhat.com/arjanv/2.6/(...)
Mais c'est pour RedHat 9 et non RedHat 8.0.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à -3.
- glib est un problème de performance pour utiliser Gstreamer dans KDE
- les bindings ça ne sert à rien
- KDE et ARTS n'ont rien à voir ou presque
- glib est une horreur pour faire des binding en C++
- Qt ne dépent pas X11 (aujourd'hui)
- J'emmerde toutes les développeurs KDE qui sont tous des crétins (fallait bien que je les insulte quelque part).
- etc...
La vérité est rétablie. Dommez tranquille.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Je ne sais pas ...
Par exemple utiliser gstreamer en C++.
Ou utiliser ce sympathique programme en python qui utilise Gnome :
http://meld.sourceforge.net/(...)
Ou avoir yum qui utilise le binding python de rpm (qui est aussi utilisé par up2date, anaconda, etc).
Si tu connais php tu peux faire des applis graphique en php :
http://gtk.php.net/(...)
J'arrête là car je n'y comprend rien à vos arguments.
# Re:
Posté par 007 . En réponse au message Le module du cdrom ne se charge pas automatiquement. Évalué à 1.
alias block-major-3-* ide-probe-mod
alias block-major-22-* ide-probe-mod
alias block-major-33-* ide-probe-mod
alias block-major-34-* ide-probe-mod
alias block-major-56-* ide-probe-mod
alias block-major-57-* ide-probe-mod
alias block-major-88-* ide-probe-mod
alias block-major-89-* ide-probe-mod
alias block-major-90-* ide-probe-mod
alias block-major-91-* ide-probe-mod
modprobe a complètement changé entre 2.4 et 2.6.
Faut aussi mettre à jours modutils (et d'autres trucs mais j'ai oublié). Sinon ça ne marchera jamais.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
Ils sont présentement à la version suivante.
Pour vous le présent, c'est la version futur.
Je sais, je répète. J'ai (ou j'avais ?) un peu de mal avec le concept.
Rassures toi, ça ira (ou ça va ? le présent c'est le futur..), heu non..
Rassures toi ça va mieux demain. Heu non plus.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Très bien.
KDE ne supporte pas le son.
KDE n'a jamais eu de serveur de son.
C'est un add-on que les distribution ajoutent.
J'ignorais.
J'ai toujours du mal à comprend pourquoi kdelib en dépend...
Et pourquoi lorsque je fait "./configure --help | grep arts" dans les sources de kdelib (sans patch) j'ai :
--without-arts build without aRts default=no
Si actuellement je vois arts sur le site de KDE :
http://www.kde.org/areas/multimedia/(...)
KDE Multimedia
Welcome to the KDE Multimedia site!
(...)
In KDE 2 and 3 these interfaces are largely built on the daemon and libraries of the Analog Real-Time Synthesizer, known as aRts.
(...)
These pages provide information on KDE multimedia and aRts.
C'est parque mon pétard n'était pas frais.
Maintenant tu peux faire comme Alex et dire que je suis bouché, et que je ne veux pas comprendre etc.
Non, ça je ne veux pas comprendre.
> Va sur le site de Arts, tu vera que ce n'est pas un projet Kde.
Vas sur le site de gtreamer, tu verras que ce n'est pas un projet Gnome.
Donc Gnome n'a aucune dépendance avec Gstreamer ?
Ben si, Gnome dépend de Gstreamer.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Faut être conhérent avec moi sinon je suis dure de l'oreille. Jusqu'à maintenant et après beaucoup de requêtes, j'ai _AUCUN_ exemple de plus "C++ friendly" que par exemple gstreamer avec glib.
Le seul argument, et il est récurrent, est :
- le C++ est plus "C++ friendly"
Tu m'étonnes... que je suis d'accord. Mais ce n'est en rien convaincant.
De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.
Le seul argument qui mérite un peu d'être vérifié est par rapport à openssl que je ne connait pas. Mais openssl n'a rien pour aider de façon générique les bindings en language objet.
> on crutique ton "C++ friendly" a propos de la glib
Ben critiquez mieux.
btw, ça revient à critiquer glib et dire que glib n'est pas "C++ friendly" et non seulement à critiquer mon "C++....
glib n'a peut-être pas été faite pour être spécifiquement "C++ friendly" mais elle a été fait pour être objet friendly. Les bindings en languages objets de gtk+ le prouve.
Le C++ à part être "C++ friendly" est assez limité dans ce domaine.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Parce c'est une lib métier.
glib ne sert à rien si j'ose dire...
> et sur quoi tu te bases pour "sentir" ça ?
La preuve, toi :
- "c'est un ajout de travail qui fait de plus doublon avec ce que déjà le C++"
- "je pense quand même que c'est une perte de temps vu ce qu'elle apporte par rapport a des framework C++"
En gros, la programmation objet si ce n'est pas en C++, c'est doublon ou moins bien et donc inutile.
Et puisqu'on est sur les bindings, il est beaucoup plus facile de faire des bindings si la librairie de base est en C qu'en C++.
Faire le binding d'une librairie C++ qui utilise tout les fonctionnalités C++ est pratiquement impossible (ou c'est immonde). Pour preuve, les bindings de librairies C++ sont rares ou alors se sont des bindings vers java ou C#.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à -1.
Qt dépend de X11.
Ça sera faux mais pour l'instant c'est vrai.
Bonne nouvelle, il est jamais trop tard pour bien faire...
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
Mouaifff...
Combiens de programme/lib kde utilisent arts ?
Tu peux aussi dire que KDE n'utilise pas libX11 ni la librairie C alors.
kdelib utilise arts.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
J'amais content.
Ben faites votre Kstreamer dans votre coin qui sera "nobody friendly" et arrêter de critiquer le boulot des autres car il n'est pas "KDE friendly" alors que vous avez une attitude hostile à tout.
> je pense qu'elle doit venir d'esound
esound n'utilise pas glib (que la libc et alsa).
C'est arts (KDE) qui utilise glib.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à -1.
Trouves une lib (non C++ puisque Gtk+/Gnome est en C pour supporter le binding) qui est plus "C++ friendly". Un truc en Java ou C# ? Désolé mais c'est pas la même catégorie.
Le développeur KDE qui fait le wrap gstreamer trouve ça facile à réaliser.
J'ai vu plus bas : APR, NSPR (j'ignore volontairement openssl).
En quoi elles sont mieux ?
glib/apr/nspr ont toute été faite en même temps environ (à un an près. glib est plus vieille mais était au début intégrée à gtk+).
Il me semble peut probable de voir une nouvelle librairie de ce type.
Puis glib est nettement plus utilisée. Non que les autres soit de moins bonne qualité (je ne connait pas nspr). apr est "limité" à apache et subversion (qui utilise aussi apache) et nspr à mozilla.
Peuvent-elles supporter la programmation objet pour faire de "joli" binding C++ ?
Je sens qu'on va encore me répondre un truc du style "la programmation object est réservé aux élites du C++".
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
> le C++ gère les signaux et les "properties" ? Non ?
Je n'ai pas envis de rentrer dans le technique, mais ce qui m'énerve le plus dans "pourquoi ne pas faire du C++", c'est ce côté "la programmation object c'est pour C++ et pas pour les autres".
Le premier bouquin sur le C ("Le langage C" par Kernighan et Ritchie) indiquait qu'un bon programme était souvent orienté objet.
Suffit de regarder les sources de Linux pour détecter rapidement des parties orientées objets. Évidemment, ce n'est pas aussi luxueux que le C++ et on peut chipoter sur mon emploi de "orienté objet".
btw, faire de l'orienté objet avec du C est très vieux (libXt est un très bon exemple).
À la question "pouquoi faire de l'objet avec du C", je réponds :
- "Car la programmation objet c'est bien et le language C c'est bien."
> > si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi
Qt est GPL. L'objectif de Gnome est d'avoir des librairies LGPL.
Qt ne permet pas les bindings (ou ce n'est pas terrible à de très rare exception).
Qt est payant sous Windows.
Qt est C++, il faut donc compiler l'appli avec un compilateur C++ (Il y a des techniques pour éviter ce problème mais c'est particuliairement ugly).
Qt dépend de X11 (et de plein d'autre trucs) alors que glib ne dépend que de la libc. Idéal aussi pour un programme non graphique. Donc rien à voir.
> 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.
Absolument. Surtout que l'empreinte mémoire de glib (hors gobject) est ridicule. Et en fait n'est chargé en mémoire que ce qui est utilisé.
De plus la multiplication des implémentations de list, hash table ... fait que ça bouffe plus de mémoire que si tout le monde utilisait la glib.
Du gâchis en place mémoire et en temps de développement et pour faire plaisir à "qques extrémistes kdeiens..." comme tu le dis.
PS : glib est un lib vraiment bien foutu. Un must pour développeurs C et quelque soit le type d'appli (graphique ou non).