Si certains s'inscrivent et n'ont pas de parrain, ça me ferait toujours plaisir qu'ils deviennent mes fillots :)
Il suffit de préciser mon email dans le formulaire : xavier66 AT free.fr
En effet, je dois être naïf pour avoir laissé ces commentaires en espérant une réponse sensée et constructive.
Comme d'habitude, tu ne sais parler que de gst, à croire qu'il n'y a que ça dans la vie. Pour ma part, gst devrait déjà faire ses preuves pour les besoins de base (cf les commentaires plus haut) avant de vouloir révolutionner le cinéma grand public :D
>> - Comme dit plus haut, c'est du "sucre" pour les développeurs
> Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé. L'API de phonon pourra être étendue au fil des avancées des backends, mais sera toujours sous contrôle. Et non, ce n'est pas un travail surhumain de maintenir phonon.
Oui, on a compris, microsoft est la fine fleur du développement et ubuntu c'est des branques. Maintenant, va jouer ailleurs.
Le monde du logiciel libre travaille avec des moyens limités, et l'erreur est humaine. Canonical n'est pas une grande multinationale qui peut se payer un contrôle qualité au top du top. Peut-être même que Rodrigo Parra Novo (l'auteur du cafouillage selon les changelogs) n'est pas employé par Canonical mais un bénévole (la flemme de chercher la liste du personnel :p), il mérite une grosse fessée mais pas que tu dénigres autant son travail.
Vu que c'est un journal public et qu'il ne va pas disparaître avant deux semaines, je sens que le troll ci-dessus a encore de belles heures devant lui. Ça me désole.
J'avais évité de mettre le pied dedans vu que l'on tourne en rond et que finalement, je ne sais plus vraiment ce que cherche à démontrer clearstream, mais je vais essayer de faire un petit récapitulatif. (Attention, je me mets au C++/Qt mais je ne connais pas tous les boyaux de KDE/Qt, donc corrigez moi si je me trompe. Qui plus est, pas la peine de me traiter de fanboy KDE, car j'ai utilisé KDE et Gnome en alternance pendant quelques années avant de me poser chez KDE pour le moment. Je laisserai aussi le côté "KDE dénigre Gnome" et "KDE c'est ils jouent perso" de côté pour recentrer sur la technique.)
- Les développements de KDE et de QT sont intimement liés, avec une version majeure de QT précédent une version majeure de KDE. Il faudra que je me renseigne plus en avant sur ces liens ;)
- QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à http://linuxfr.org/comments/745544.html#745544 ]
- Malheureusement, rien n'est prévu dans QT4 pour le son (vu que c'est à la base un toolkit graphique quand même :p). L'idée est venue de faire l'encapsulation d'un framework multimedia pour avoir les mêmes avantages que QT pour les graphismes : stabilité d'API/ABI et syntaxe objet unifiée avec le reste (et portabilité aussi si possible).
- Vient alors la question du framework à encapsuler. L'avantage de l'encapsulation est qu'on peut fournir la même API en passant par n'importe quel backend s'il est supporté. Le fait de supporter plusieurs backends est un plus, pas le but recherché. Qui plus est, ça arrange ceux qui ont des mauvais souvenirs avec arts ;)
- Non, ce n'est pas une somme de travail immense de rajouter le support d'un backend, c'est écrire quelques fonctions de quelques lignes. Si l'API d'un backend change, il n'y a qu'à modifier ces fonctions, recompiler phonon et tout va bien. J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
- Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...), on ne parle pas de MAO et de temps réel là. Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
- Comme dit plus haut, c'est du "sucre" pour les développeurs, rien qui n'impacte directement luce et henry, à part des soucis en moins dans amarok quand gstreamer change d'API ou quand xine ne veut pas marcher avec dmix.
J'espère n'avoir pas dit trop de bêtises. Maintenant, clearstream, qu'est-ce qui te révolte tant ?
Je ne pense pas qu'il faille voir un jugement de valeur dans toutes ces annonces, si ce n'est qu'AMD a tout fait pour que sa technologie x86-64 soit adoptée dans l'industrie. Et pour cela, il fallait des logiciels qui tirent parti des instructions supplémentaires.
L'itanium d'intel a été un échec du fait du manque d'applications et AMD a fait son possible pour éviter le même écueil à sa technologie, en mangeant à tous les ratteliers. En informatique, ce qui compte n'est pas tant la supériorité technologique que la puissance marketing (voyez microsoft).
Drupal permet l'import d'articles depuis un fichier XML (format DXML), il suffirait donc d'obtenir un export en XML de tes articles SPIP (par exemple un flux atom) et passer une moulinette XSLT dessus pour ensuite importer le résultat dans drupal.
Sinon, il y a un module importhtml ( http://drupal.org/project/import_html ) qui pourrait peut-être t'aider, mais là c'est assez porc comme méthode :)
Quatre journaux en une heure, on peut dire que tu es productif :)
Pourquoi ne pas les avoir regroupées en un seul gros journal "du nouveau sur les licences libres" ?
Je dois faire un choix de CMS sous peu, et le truc qui me bloque avec SPIP est le manque d'organisation dans la documentation (ou le manque de doc peut-être ?).
Je suis peut-être idiot, mais je n'ai même pas réussi à trouver une référence _exhaustive_ de la syntaxe pour insérer des images sur la doc de spip.net.
Mon deuxième grief vient du langage de templates et boucles. J'aurais vraiment préféré utiliser du XHTML et des snipplets en PHP comme modX ( http://modxcms.com ). Peut-être que la syntaxe spip est facile, mais c'est pas la doc existante qui va m'aider à l'aimer :/
En fait, ça dépend des fontes choisies pour l'affichage. Enfin, le test acid2 est quand même granguinolesque, d'où les résultats un peu aléatoires : http://bugs.kde.org/show_bug.cgi?id=117373
En effet, le test ACID2 passe avec opera 9, par contre c'est moi ou il ne passe plus avec mon konqueror 3.5.3 tout fraîchement apt-getté ? C'est un petit peu dommage :/
Pour la partie communication avec l'afficheur, je n'ai pas de piste à part sniffer, mais pour le reste, tu peux regarder du côté de lcd4linux ( http://lcd4linux.bulix.org ) qui possède une architecture par plugins. Il te suffira d'écrire le driver d'affichage (quelques fonctions dépendantes du matos à implémenter), en t'aidant des autres drivers (il y a déjà des écrans usb supportés). Contacte la ML développeurs pour de l'aide sur l'écriture.
Si elle permet de connecter plusieurs clients simultanément, elle fait donc du NAT et toutes les connections entrantes sont bloquées par défaut. Par exemple, la 9box ne fait pas routeur NAT : même en ethernet elle fait modem pppoe.
De toute facon, dès qu'il y a un routeur entre l'ordi et le net et qu'il ne laisse pas passer les connections entrantes (NAT normal sans forwarding), c'est un "mur de feu" (oui, la traduction pare-feu me fait hérisser les poils à chaque fois)
La limitation aux IP free annoncée ne l'était que pour les comptes ouverts après mars (ou mai) 2005, et je n'ai pas eu de confirmation sur sa mise en application. Pour un compte plus ancien, tu peux t'y connecter depuis le guatemala sans problème
- pour faire un truc comme ca il ne faut pas les lignes Auth*
- ton idée ne marchera pas car les requêtes sur les images seront faites par le client, pas par le serveur (tu me suis ?)
- je vois vraiment pas l'intérêt d'une telle infraction aux règles élémentaires du net, mais bon ...
Sous KDE je ne sais pas exactement. Essaie de passer par kcontrol pour effectuer le pairage avant tout. Il y a une entrée bluetooth dans le panneau de controle pour détecter et pairer les périphériques bluetooth
C'est un code quelconque que tu dois tapper à l'identique sur les deux peers, donc sur ton ordi et ton téléphone. C'est la procédure standard de pairage pour s'assurer que tu as un accès physique au périphérique et que ton voisin ne fasse pas joujou avec ton phone ou ton imprimante
Oui, mais par rapport à l'intégration kopete/kontact (et konqueror kontact), la solution gevolution est vraiment inutilisable. Comme moi, regarde comment ca marche chez kopete, et gaim te semblera archaique.
Pour finir (et répondre à la question), personne ne peut conseiller un bureau plutot qu'un autre à quelqu'un. C'est une question de préférences personelles et d'atentes de l'utilisateur. Certains préfèreront fluxbox pour la légèreté, d'autres KDE pour l'eye-candy, un autre GNOME pour sa simplicité, ou KDE pour son intégration, certains irréductibles le shell ;)
Le mieux est encore de laisser le choix à ta soeur, mais je pense que KDE est plus approprié pour les jeunots qui sortent de XP
Personellement, j'ai pas mal alterné entre les deux bureaux : KDE1, KDE2, GNOME 1.4 jusqu'à 2.10 et maintenant KDE 3.4.
J'ai beaucoup aimé GNOME 2 pour sa simplicité, son impression de légèreté, sa sobriété. Mais s'il y a un reproche que je dois bien faire à ce bureau est son manque d'intégration, par exemple entre gaim et evolution. Pour la légèreté, en passant sur un thinkpad avec un joli disque dur IBM aux performances déplorables, j'ai souffert (lancement d'evolution ou de firefox).
D'un autre côté, j'avais testé KDE 3, mais jusqu'à la version 3.4, c'était trop "usine à gaz" pour moi (toujours, une impression générale et subjective). Il a fallu que je teste le KDE 3.4 de la kubuntu pour me remettre à aimer KDE ! L'utilisation de konqueror, kopete, kontact (intégration de kmail, akregator et tout la clique) m'a bluffé. Le maître mot est "intégration" ! Le bureau est cohérent et plus réactif. Un travail d'optimisation a du être bien mené car tout mon bureau est plus rapide à utiliser, bien que plus lent à charger initialement (mais qui n'utilise pas encore l'hibernation ?)
# Parrainage
Posté par xavier66 . En réponse au journal Devenez moins pauvre grâce à la recherche !!. Évalué à -3.
Il suffit de préciser mon email dans le formulaire : xavier66 AT free.fr
[^] # Re: Au secours
Posté par xavier66 . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 5.
Comme d'habitude, tu ne sais parler que de gst, à croire qu'il n'y a que ça dans la vie. Pour ma part, gst devrait déjà faire ses preuves pour les besoins de base (cf les commentaires plus haut) avant de vouloir révolutionner le cinéma grand public :D
>> - Comme dit plus haut, c'est du "sucre" pour les développeurs
> Il vont peut-être s'économiser 10 lignes de code pour rester enchaîné à Phonon. Au moins avec ce sucre ils ne risque pas grossir.
L'avantage est _jutement_ de ne pas s'enchaîner à un élément extérieur non maîtrisé. L'API de phonon pourra être étendue au fil des avancées des backends, mais sera toujours sous contrôle. Et non, ce n'est pas un travail surhumain de maintenir phonon.
[^] # Re: Au secours
Posté par xavier66 . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 2.
[^] # Re: Au secours
Posté par xavier66 . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
[^] # STOP !
Posté par xavier66 . En réponse au journal Ubuntu : La MAJ de xserver-xorg fait planter le serveur X. Évalué à 0.
Le monde du logiciel libre travaille avec des moyens limités, et l'erreur est humaine. Canonical n'est pas une grande multinationale qui peut se payer un contrôle qualité au top du top. Peut-être même que Rodrigo Parra Novo (l'auteur du cafouillage selon les changelogs) n'est pas employé par Canonical mais un bénévole (la flemme de chercher la liste du personnel :p), il mérite une grosse fessée mais pas que tu dénigres autant son travail.
# Au secours
Posté par xavier66 . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 9.
J'avais évité de mettre le pied dedans vu que l'on tourne en rond et que finalement, je ne sais plus vraiment ce que cherche à démontrer clearstream, mais je vais essayer de faire un petit récapitulatif. (Attention, je me mets au C++/Qt mais je ne connais pas tous les boyaux de KDE/Qt, donc corrigez moi si je me trompe. Qui plus est, pas la peine de me traiter de fanboy KDE, car j'ai utilisé KDE et Gnome en alternance pendant quelques années avant de me poser chez KDE pour le moment. Je laisserai aussi le côté "KDE dénigre Gnome" et "KDE c'est ils jouent perso" de côté pour recentrer sur la technique.)
- Les développements de KDE et de QT sont intimement liés, avec une version majeure de QT précédent une version majeure de KDE. Il faudra que je me renseigne plus en avant sur ces liens ;)
- QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à http://linuxfr.org/comments/745544.html#745544 ]
- Malheureusement, rien n'est prévu dans QT4 pour le son (vu que c'est à la base un toolkit graphique quand même :p). L'idée est venue de faire l'encapsulation d'un framework multimedia pour avoir les mêmes avantages que QT pour les graphismes : stabilité d'API/ABI et syntaxe objet unifiée avec le reste (et portabilité aussi si possible).
- Vient alors la question du framework à encapsuler. L'avantage de l'encapsulation est qu'on peut fournir la même API en passant par n'importe quel backend s'il est supporté. Le fait de supporter plusieurs backends est un plus, pas le but recherché. Qui plus est, ça arrange ceux qui ont des mauvais souvenirs avec arts ;)
- Non, ce n'est pas une somme de travail immense de rajouter le support d'un backend, c'est écrire quelques fonctions de quelques lignes. Si l'API d'un backend change, il n'y a qu'à modifier ces fonctions, recompiler phonon et tout va bien. J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
- Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...), on ne parle pas de MAO et de temps réel là. Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
- Comme dit plus haut, c'est du "sucre" pour les développeurs, rien qui n'impacte directement luce et henry, à part des soucis en moins dans amarok quand gstreamer change d'API ou quand xine ne veut pas marcher avec dmix.
J'espère n'avoir pas dit trop de bêtises. Maintenant, clearstream, qu'est-ce qui te révolte tant ?
[^] # Re: amd et microsoft et l'OSDL
Posté par xavier66 . En réponse au journal AMD rachète ATI... c'est officiel. Évalué à 9.
L'itanium d'intel a été un échec du fait du manque d'applications et AMD a fait son possible pour éviter le même écueil à sa technologie, en mangeant à tous les ratteliers. En informatique, ce qui compte n'est pas tant la supériorité technologique que la puissance marketing (voyez microsoft).
[^] # Re: Migration Spip -> Drupal
Posté par xavier66 . En réponse à la dépêche Sortie de SPIP 1.9. Évalué à 1.
Sinon, il y a un module importhtml ( http://drupal.org/project/import_html ) qui pourrait peut-être t'aider, mais là c'est assez porc comme méthode :)
# Productif, n'est-il pas ?
Posté par xavier66 . En réponse au journal Deux nouvelles soeurs dans la famille des licences Cecill!. Évalué à 4.
Pourquoi ne pas les avoir regroupées en un seul gros journal "du nouveau sur les licences libres" ?
# Documentation ?
Posté par xavier66 . En réponse à la dépêche Sortie de SPIP 1.9. Évalué à 1.
Je suis peut-être idiot, mais je n'ai même pas réussi à trouver une référence _exhaustive_ de la syntaxe pour insérer des images sur la doc de spip.net.
Mon deuxième grief vient du langage de templates et boucles. J'aurais vraiment préféré utiliser du XHTML et des snipplets en PHP comme modX ( http://modxcms.com ). Peut-être que la syntaxe spip est facile, mais c'est pas la doc existante qui va m'aider à l'aimer :/
Et vous, vous utilisez quel CMS ?
[^] # Re: Le tag ?
Posté par xavier66 . En réponse au journal [2007] Projet Socialiste, Licence globale où Taxes Tasca ?. Évalué à 3.
[^] # Re: Honte sur moi !
Posté par xavier66 . En réponse au journal Opera 9 is out. Évalué à 1.
[^] # Re: Honte sur moi !
Posté par xavier66 . En réponse au journal Opera 9 is out. Évalué à 1.
# LCD4Linux
Posté par xavier66 . En réponse au journal Afficheur digital et Linux. Évalué à 2.
[^] # Re: Taille des packets réseaux
Posté par xavier66 . En réponse au message [Ubuntu] NAT assez capricieux. Évalué à 1.
Solution : rajouter
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o ppp0 --clamp-mss-to-pmtu
Bizarre que ça ne se manifestait pas avant !
# Reached the maximum number of concurent connections on this server
Posté par xavier66 . En réponse au journal Votre bureau KDE accessible de n'importe où !. Évalué à 3.
[^] # Re: beh
Posté par xavier66 . En réponse au message [kubuntu] accès ssh derrière une freebox !. Évalué à 1.
# Si elle fait NAT, oui
Posté par xavier66 . En réponse au message adsl, truc-box et firewall. Évalué à 1.
De toute facon, dès qu'il y a un routeur entre l'ordi et le net et qu'il ne laisse pas passer les connections entrantes (NAT normal sans forwarding), c'est un "mur de feu" (oui, la traduction pare-feu me fait hérisser les poils à chaque fois)
# Limitation chez free ?
Posté par xavier66 . En réponse au message Echange de fichier inter sidéral !. Évalué à 1.
# Trois choses
Posté par xavier66 . En réponse au message Soucis de .htaccess Apache ... allow from non pris en compte. Évalué à 1.
- ton idée ne marchera pas car les requêtes sur les images seront faites par le client, pas par le serveur (tu me suis ?)
- je vois vraiment pas l'intérêt d'une telle infraction aux règles élémentaires du net, mais bon ...
[^] # Re: C'est juste un code ;)
Posté par xavier66 . En réponse au message bluetooth téléphone et obex : demande de code. Évalué à 2.
# C'est juste un code ;)
Posté par xavier66 . En réponse au message bluetooth téléphone et obex : demande de code. Évalué à 5.
[^] # Re: Allez, on va essayer d'être constructif
Posté par xavier66 . En réponse au message Attention au troll : Gnome vs KDE. Évalué à 2.
[^] # Re: Allez, on va essayer d'être constructif
Posté par xavier66 . En réponse au message Attention au troll : Gnome vs KDE. Évalué à 2.
Le mieux est encore de laisser le choix à ta soeur, mais je pense que KDE est plus approprié pour les jeunots qui sortent de XP
# Allez, on va essayer d'être constructif
Posté par xavier66 . En réponse au message Attention au troll : Gnome vs KDE. Évalué à 4.
J'ai beaucoup aimé GNOME 2 pour sa simplicité, son impression de légèreté, sa sobriété. Mais s'il y a un reproche que je dois bien faire à ce bureau est son manque d'intégration, par exemple entre gaim et evolution. Pour la légèreté, en passant sur un thinkpad avec un joli disque dur IBM aux performances déplorables, j'ai souffert (lancement d'evolution ou de firefox).
D'un autre côté, j'avais testé KDE 3, mais jusqu'à la version 3.4, c'était trop "usine à gaz" pour moi (toujours, une impression générale et subjective). Il a fallu que je teste le KDE 3.4 de la kubuntu pour me remettre à aimer KDE ! L'utilisation de konqueror, kopete, kontact (intégration de kmail, akregator et tout la clique) m'a bluffé. Le maître mot est "intégration" ! Le bureau est cohérent et plus réactif. Un travail d'optimisation a du être bien mené car tout mon bureau est plus rapide à utiliser, bien que plus lent à charger initialement (mais qui n'utilise pas encore l'hibernation ?)