Justement, si un provider bloque ce port, il va quand même emmerder pas mal ses abonnées qui veulent utiliser gnutella. Ils peuvent changer de port, mais comment font-ils alors pour s'integrer avec d'autres utilisateurs qui auront gardé le même ?
Ou sinon tu peux imaginer qu'ils detectent les requetes http descendantes (vers un abonné) et bloque ça aussi. C'est moins facile à faire mais réalisable.
je pense que vu l'augmentation constante des vitesses de transfert de données sur internet, le fait que les réseaux gnutella gâchent de la bande passante n'est pas trop un problème
Euh, tu as regardé un peu les chiffres qu'il donne ? C'est une croissance exponentielle bien supérieure à celle qu'on peut espérer pour la bande passante du Net.
incontrolable, intracable, inattaguable.
Je ne crois pas. Un provider peut configurer ses routeurs pour empecher ses clients d'utiliser Gnutella.
C'est pas parce que l'indentation est bien respectée que ça fait du bon code.
Les règles de qualité vont en général un peu au dela des questions d'indentation. :-)
Je suis vraiment pas convaincu qu'on puisse mettre le bon code en règles.
Je suis même convaincu qu'on ne peut pas :-). Par contre tu peux un peu limiter la casse. Il ne s'agit pas de n'accepter que du bon code mais plutôt d'essayer d'en rejeter le plus de mauvais possible. Le problème étant que tu peux souvent en arriver à jeter du bon code aussi. Un peu comme les filtres anti-spam quoi.
Bref, le fond de ma remarque c'est plutôt qu'MS se fout probablement pas mal de piquer du code libre, même du code du kernel Linux ou *BSD.
Et si MS reprenait du code libre (meme tout a fait légalement), il irait le chercher où ? [...]
Oui, tu as tout à fait raison Ceci dit, récuperer du code n'est jamais chose aisée, et dans 99% des cas tu préfères le ré-écrire en repiquant simplement quelques infos. Donc même si MS pouvait repiquer ce qu'ils voulaient dans le libre, ils ne le ferait sans doute pas.
Ahhh, oui, tu as raison, je dois confondre. Bon, je sais que le mac fait ça depuis un bon moment aussi (là j'en suis sur, j'en utilisais un vieux encore récemment), et je suis quasi-sur que NT le faisait, mais pour les versions plus anciennes tu as sans doute raison.
Ceci dit, il est certain que ça n'est pas à Linux que Windows à piqué ça.
Oui, mais ça c'est normal, une boite qui ne regarde pas ce qui se passe autour d'elle pour piquer les bonnes idées ne vas pas aller bien loin.
En plus le login graphique existe depuis bien avant XP (NT l'avait déjà), et il y a des petits utilitaires qui refont les bureaux virtuels sous Win depuis longtemps. Quant au rappel des derniers programmes utilisés, ça c'est plutôt KDE ou Gnome qui l'ont repris à Win.
Il y a probablement beaucoup plus de mauvais code dans l'open source que chez MS.
Faut pas réver non plus, à part quelques projets vraiment bons, si tu prends un truc sur freshmeat tu as de bonnes chances de tomber sur du code qui ne passerait pas les règles de qualité de n'importe quelle entreprise (y compris MS, qui a la réputation d'être assez strict de ce coté là, si difficile à admettre que ça le soit).
Ça n'est pas parce qu'il fait de l'open source que l'étudiant moyen qui fait son projet tout seul chez lui va se mettre à programmer comme un dieu. Même pire, comme il est souvent convaincu que faire de l'open source implique faire du bon code, il risque encore moins de se remettre en question.
Je m'explique : qu'on ne vienne pas me dire que la dernière version de l'explorer de XP n'utilise pas du code de Konqueror/Nautillus car je ne le croirai pas. Il suffit de regarder les thumbnails pour s'en rendre compte.
c'est pour cela que le "libre" est une garantie pour limiter la casse en cas de rupture de service du fournisseur.
Une éventuelle possibilité oui, une garantie surement pas, hélas. C'est pas si simple de reprendre ou faire reprendre du code plus ou moins bien fait et documenté.
Y a pas que des fautes d'orthographes, y a aussi carrément des contresens :
"Enfin, celui qui a le plus de succès est le timide. Il les attendrit toutes. Par son mysticisme, les femmes veulent en connaitre plus et elles vont l'accoster."
C'est que pour moi le composant de KWord n'a pas à se lancer ailleurs que dans KWord.
Interessant comme point de vue :-). Et quel est alors l'interêt d'en faire un composant ?
Pour moi permettre à d'autres applications qu'un traitement de texte d'afficher un document kwd ne sert à rien à part à compliquer les choses pour l'utilisateur débutant.
D'après mon expérience, ça ne semble pas être le cas.
Ça n'aide certainement pas à faire la distinction entre un gestionnaire de fichiers, un traitement de texte...
Mais pourquoi aurait-il à la faire ? Il n'y a aucune loi qui dit que cette distinction soit obligatoire, nécéssaire, ou même utile. L'utilisateur veut juste rédiger ses textes, ce genre de distinctions il s'en fout complètement.
Ceci dit les gens sont capables de choisir entre un portable Nokia ou Siemens
Mais contrairement aux toolkits, un portable siemens peut marcher sur n'importe quel réseau et appeller ou être appelé par n'importe quel portable. Tout ça est standardisé et compatible.
Pour un développeur, devoir choisir entre plusieurs toolkits implique qu'il va devoir passer du temps à évaluer chaque toolkit, puis à imposer à ses utilisateurs d'avoir la toolkit choisie installée et à jour. Pour du free, il va aussi imposer l'API a ceux qui veulent participer. Pour du commercial, à ses collaborateurs.
Dans le cas de Linux c'est pas trop un pb, toutes les distribs installent toutes les toolkits. Pour les autres Unix, y a que Motif et Athena en standard, et installer une toolkit n'est pas forcément trivial (faut souvent être root, avoir un accès à l'extérieur pour downloader l'archive, etc...). Windows n'a jamais posé ce pb à ses développeurs, et ça a été un avantage énorme.
Il n'y a qu'a voir le nombre de projets qui sont des portages d'un projet existant vers une autre toolkit. Est-ce vraiment interessant de faire ce genre de boulot ? Est-ce que le temps qu'on y consacre ne pourrait pas être mieux utilisé à améliorer l'appli de départ ? Et toi qui râle contre les trucs lourds, crois-tu qu'avoir plusieurs toolkits en mémoire (lance xterm, galeon, ddd et kword : 4 toolkits) soit une bonne chose ?
Pourquoi crois-tu que toutes les plateformes de dev récentes (BeOS, Java, .NET...) spécifient quasiment tout, y compris et surtout le graphisme ? L'industrie a compris la leçon.
Au moins sous Linux maintenant ça se décide entre GTK+ et Qt, les autres ont quasi disparu. Les choses s'améliorent.
Quant aux WM, là c'est pire : rien que faire comprendre le concept de window manager à un utilisateur de base, c'est ridicule. Et c'est aussi c'est une grosse source d'emmerdes pour les développeurs, avec des WMs qui sont plus ou moins IEEE compliant, les thèmes qui marchent plus ou moins bien, etc...
mais pour moi s'il s'agit d'intégrer un moteur d'affichage HTML dans un prog, une bibliothèque convient.
Dans le cas d'une fonction simple et bien définie comme celle-ci, oui, sans doute.
Donc pour afficher un .doc, pas besoin d'un "composant" de traitement de texte, je veux juste qu'Abiword se lance, par exemple.
Je re-repête : un composant fait que ça revient au même. C'est même beaucoup plus leger qu'un lancement d'appli. KWord est juste une envoloppe minimale autour d'un composant, le même composant que lance Konqueror lorsque tu cliques sur un .kwd.
Puisque je veux avoir le choix, explique moi pourquoi il n'est pas important.
Parce que si tu ne l'avais pas, ça ne t'empècherait pas de travailler, et que d'ici quelques années tu ne te préoccupera sans doute plus de l'avoir.
En fait je met les implications dans l'autre sens.
Elles sont fausses dans l'autre sens aussi. Utile et bien programmé n'implique pas que le résultat soit leger, etc...
j'ai peut-être un peu plus de facilités pour juger ce qui est lourd parce qu'on ne peut pas faire autrement, et ce qui est lourd parce que c'est soit mal concu soit inutile.
Non. J'ai arreté d'avoir ce genre d'a priori sur des programmes après quelques années dans l'industrie, et m'être rendu compte que j'avais le plus souvent tord quand je jugeais qu'un programme était mal fait ou trop lourd. En pratique tu ne fais jamais de bons programmes, tu essaies de les faire le moins mauvais possible.
Ce que je voulais dire c'est que tes critères de jugement ne sont pas les mêmes que ceux du consommateur moyen, mais pas meilleurs (même plutôt moins bon, en fait). Il y a des choses qui sont importantes pour toi et qui indiffèrent le consommateur moyen (le choix d'une toolkit ou d'un WM), et inversement (l'intégration des softs).
Si ça peut te rassurer sur mon ouverture au monde je ne suis pas en école d'info
Tant mieux pour toi (c'est pas une critique, ou plutôt si, une critique des écoles d'infos :-).
Mais, c'est quoi l'image caricaturale que je m'en fais ?
Quelque chose comme :
Leger => utile et bien programmé
Lourd => inutile et mal programmé
Si tu comprends que ces deux assertions sont fausses, alors on est d'accord.
Donc en bon consommateur moyen je dis "c'est de la merde"
Non, tu n'es pas un consommateur "moyen", justement. Tu as certaines connaissances en informatique qui font que ton jugement est complètement différent de la moyenne. Tu ne prends pas les mêmes choses en considération.
Si je résume grossièrement, tu nous dit qu'il ne faut pas développer de logiciels légers comme ion, il faut acheter une nouvelle machine.
Non, je dis juste que c'est comme ça que ça se passe dans la réalité, et que ça n'est pas forcément pour de mauvaises raisons comme tu sembles le penser (les développeurs ne font pas de la merde avec des surcouches inutiles).
Il ne faut pas non plus vouloir écouter de la musique avec ce que l'on a, mais acheter un lecteur.
Non. Je dis que tu aura probablement un meilleurs résultat comme ça. Enfin bon, sur ce plan là je concède que le mp3 a quelques avantages sur le CD normal, si ça peut te faire plaisir :-).
Et ailleurs tu me dis que je ne devrais pas vouloir avoir le choix d'un WM ou d'un toolkit.
Non, je dis que ce choix n'est pas important. Et même que ce choix a beaucoup handicappé Unix sur le desktop.
Relis mes posts. Je ne te dis pas "il faut faire ci ou ça", je te dis juste comment les choses se passent en dehors de ton école d'info, et que le monde du logiciel, libre ou proprietaire, est bien plus complexe que l'image caricaturale que tu t'en fais.
Mais ne te fais aucun souci, tu découvrira tout ça par toi-même plus tard, on est tous passé par là. Et je sais que ça t'agace profondément qu'on te le dise, ça m'agaçait aussi. Mais maintenant avec un peu plus d'expérience, je suis bien forcé de reconnaitre que ceux qui me le disaient avait raison.
Dans une optique commerciale, oui, mais tu conviendras que tu t'en fous un peu lors d'un développement de type hobby.
Globalement non, bien sur, mais quand même un peu. Quand tu obtiens un résultat acceptable en 2 jours de dev, t'as pas forcément envie de passer 10 jours de plus pour un gain hypothétique. Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom. D'abord, tu ne sais quasiment jamais où tu perds le plus en perfs. N'importe quel developpeur un peu expérimenté te dira que les parties lentes de ton code ne sont jamais celles auxquelles tu t'attends. Il faut profiler ton soft pour être sur de là où tu dois chercher à améliorer les perfs.
Ensuite, dans l'optimisation tu vas obligatoirement casser quelque chose. Statistiquement, tu es presque sur d'introduire des bugs. Et si par "optimisation" tu veux dire "ré-écrire avec un langage plus rapide", là c'est pire.
Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation.
Au contraire, je suis bien placé pour savoir que c'est à l'objet ce que la mobylette est à la voiture, très lourd, et pas simple du tout à utiliser. Mais dès que tu fais de l'objet sans que ce soit supporté au niveau du langage (ie avec un langage pas objet, C ou un autre), tu vas arriver à ça. Ceci dit oui, GTK+ reste plus sympa à utiliser que Motif, mais globablement ça reste un truc assez horrible. Tu passes ton temps à faire le boulot du compilateur avec des casts à tout va et la dérivation à la main.
Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne.
Si c'est le cas, c'est que l'objet a été mal designé. Malheureusement en pratique c'est souvent vrai, mais on progresse. Il a fallu du temps pour qu'on comprenne bien comment faire de l'objet. Sur la question, je te conseille le chapitre d'intro du fameux "Design Patterns".
alors qu'on peut faire mieux sans cet amas de couches.
Oui, mais là encore au prix d'un temps de développement accru. Et encore, ça n'est pas évident que tu va gagner en perfs. Pour reprendre l'exemple de l'OO en C vs. un langage objet comme C++ : un compilo C qui voit un appel à une fonction à travers une table (pour émuler une méthode virtuelle) traduit ça tel quel, parce qu'il ne sait pas ce que c'est. Un compilo C++ sait ce qu'est une méthode virtuelle et peut le traduire de manière bien plus efficace.
C'est un peu comme si tu dictes une ordonnance médicale à quelqu'un qui n'y connait rien : il va noter scrupuleusement chaque mot, parce qu'il ne comprend pas de quoi ça parle. Si tu la donnes à un pharmacien, il va comprendre de quoi il s'agit, et par exemple pouvoir te dire que tel médicament est équivalent à tel autre qui coute moins cher, ou que ces deux médicaments là peuvent être remplacé par un seul, etc...
Un autre exemple c'est que tu peux facilement exprimer des choses plus efficaces. Par exemple, les classes de listes ou de string etc... de Qt (QList, QString, QArray...) sont bien plus efficaces qu'un équivalent en C parce qu'elle savent gerer leur données internes avec des compteurs de references, faire du Copy On Write, etc... Donc un truc du genre :
QString a = "blah"; // a copie "blah"
QString b = a; // b reference le char* interne de a
// donc pas de copie
b[0] = "c"; // b cree automatiquement sa propre copie de "blah" et la modifie
C'est impossible d'avoir ce niveau de controle en C, ça serait infernal à coder et à debugger. Donc un QString est plus gros qu'un simple char* (pas de beaucoup, quelques octets de plus), mais son utilisation est en moyenne beaucoup plus efficace.
Augmenter les couches d'abstraction coute un peu en perfs, mais t'en fait gagner beaucoup aussi. Il faut juste le temps que les compilos s'améliorent.
ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures
Mais le temps de développement coute en général plus cher que les infrastructures. En plus il y a l'utilisation ensuite.
Si tu fais un serveur en Java au lieu de C++, tu vas le finir 3 fois plus vite (c'est le gain généralement constaté je crois) et le résultat sera plus fiable qu'en C++ (Java a sa part d'emmerdes, mais globalement c'est ça). Si ton serveur fait un boulot un tant soit peu crucial et donc que chaque fois qu'il tombe ça se traduit par une perte d'argent (les gens peuvent plus bosser, les clients peuvent plus contacter le site web, etc...), le coup des machines est très vite amorti.
Il n'empèche que (toujours à mon avis), avec un peu de rigueur et avec les technos actuelles, on peu diminuer par 10 la taille des programmes et les accellérer énormément.
Oui, mais si ça augmente les délais de développement ça n'a aucun interêt. Le développement coute plus cher que le hard, et en général quand on optimise on commence surtout par introduire des bugs et casser des features. C'est pour ça que Java marche bien sur les serveurs : c'est rapide à developper, et pour combler la perte en perfs par rapport à C++ tu prends de plus grosses machines. Au final, ça coute beaucoup moins cher.
A mon avis, il est des choses qu'on ne devrait pas considérer comme normales (telle la prog objet)
Bien sur que si, au contraire. A part pour du code trivial, l'objet est toujours interessant. Dès que tu as des structures de données et des fonctions qui travaillent dessus, tu peux faire de l'objet. Ça recouvre la majorité des cas.
Il me semble qu'une approche composants / légo[...]
Là non, je suis d'accord, c'est surtout utile sur le desktop.
tu te retrouves avec une appli comme le gestionnaire de fichier de gnome, avec 150000 appels à la même ressource.
Gnome est un mauvais exemple. Ils ont voulu faire de l'objet en C en croyant que la programmation objet c'est juste du sucre syntaxique, ils le payent. Justement, c'est en voulant faire leger qu'ils sont arrivé à un truc plus lourd que KDE.
Non, là tu montres que ta structure change en taille justement pour respecter l'alignement. Tu gagnes un peu en mémoire (4 octets par item, c'est à dire quasi rien, à moins d'avoir beaucoup d'items, mais alors vraiment beaucoup), mais les perfs vont être identiques. Le compilo a donc bien fait son boulot, et ça n'est absolument pas le genre de chose dont un développeur devrait avoir à se préoccuper.
Par ailleurs, je pense qu'à un certain niveau d'optimisation il doit pouvoir réordonner les membres lui-même, mais ça peut être source de jolis bug si tu ne compiles pas tout avec le meme niveau d'optim. En pratique c'est même le genre d'optimisation que je ne voudrais pas faire : gain négligeable au runtime, énormes pertes de temps potentielles au dév.
D'un côté tu dis que les vieux logiciels ne sont plus maintenus parce que trop chers et de l'autre que si on est satisfait des vieux logiciels autant les garder.
Pardon, je clarifie : il est normal que les vieux logiciels propriétaires ne soient plus maintenus, ça coute trop cher et ça n'est pas rentable. Pour le libre, si il y en a que ça amuse de maintenir des vieux trucs c'est bien, ça peut être utile à quelques uns, mais c'est moins interessant que d'avancer. Quant à l'idée de faire des "nouveaux vieux trucs" comme Ion, alors là oui c'est complètement inutile. Mais bon, dans le libre on peut se faire plaisir, si c'est le cas pour l'auteur de Ion, très bien. Je connais bien Chris Cannam, l'auteur de wmx dont on parle plus bas, puisque je développe Rosegarden avec lui. Il a fait ça pour le plaisir aussi, il y a longtemps, et il n'ira jamais dire que c'est la seule bonne façon de faire un window manager parce qu'il ne faut pas faire de gadgets.
Mais sinon, qu'un logiciel ne soit plus maintenu, propriétaire ou pas, n'implique pas qu'il devienne du jour au lendemain inutile. Tant que ça marche, autant le garder.
Après, quand je dis "vieux logiciel", je parle d'un truc qui n'évolue plus et que pratiquement plus personne n'utilise. Ça n'est pas le cas de Window Maker par exemple. C'est pas simplement une question de nombre d'années d'existence.
Dans le même ordre d'idées, si on arrete de développer un traitement de texte (disons Ted que j'aime bien), au bout d'un an il sera incapable d'ouvrir des documents actuels.
Tu veux dire si on arrête de maintenir les filtres d'import... Oui, c'est vrai, mais je ne vois pas l'interêt d'essayer d'importer du Word récent dans un tdt tellement ancien qu'il ne saurait pas manipuler des images incluses dans le texte par exemple (je ne sais pas si Ted sait faire ça, je parle en général).
Le jour (s'il arrive) où tout le monde utilisera IPv6, les vieilles machines auront aussi besoin de savoir ce que c'est.
Pas si ça coute moins cher de les remplacer, ce qui sera très probablement le cas (sauf celles tournant sous Linux/*BSD, et encore... si le noyeau est devenu définitivement trop gros pour tourner sur un 486 ou un pentium, ben tant pis, c'est vraiment pas grave).
HTTP2 est un bon contre-exemple aussi : Netscape3 ou Mosaic sont morts, remplacés par NS4, 6, MSIE, Konq, etc... qui nécéssitent bien plus de CPU. Netscape ne va pas exhumer NS3 pour y ajouter un protocole qui ne servira à rien puisque de toute façon le browser est déjà obsolète.
[^] # Re: SVM
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Un ingé de Napster : "Gnutella ne tiendra pas la montée en charge". Évalué à 2.
[^] # Re: oui mais...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Un ingé de Napster : "Gnutella ne tiendra pas la montée en charge". Évalué à 1.
Tu manques d'imagination :
http://www.google.com/search?q=%20isp%20blocking%20port(...(...))
Des ISPs bloquent le port 80 (en entrée bien sur) ou le port 25. Pour des raisons de sécurité bien sur, mais bon...
[^] # Re: oui mais...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Un ingé de Napster : "Gnutella ne tiendra pas la montée en charge". Évalué à 6.
Ou sinon tu peux imaginer qu'ils detectent les requetes http descendantes (vers un abonné) et bloque ça aussi. C'est moins facile à faire mais réalisable.
[^] # Re: oui mais...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Un ingé de Napster : "Gnutella ne tiendra pas la montée en charge". Évalué à 8.
Euh, tu as regardé un peu les chiffres qu'il donne ? C'est une croissance exponentielle bien supérieure à celle qu'on peut espérer pour la bande passante du Net.
incontrolable, intracable, inattaguable.
Je ne crois pas. Un provider peut configurer ses routeurs pour empecher ses clients d'utiliser Gnutella.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 0.
Les règles de qualité vont en général un peu au dela des questions d'indentation. :-)
Je suis vraiment pas convaincu qu'on puisse mettre le bon code en règles.
Je suis même convaincu qu'on ne peut pas :-). Par contre tu peux un peu limiter la casse. Il ne s'agit pas de n'accepter que du bon code mais plutôt d'essayer d'en rejeter le plus de mauvais possible. Le problème étant que tu peux souvent en arriver à jeter du bon code aussi. Un peu comme les filtres anti-spam quoi.
Bref, le fond de ma remarque c'est plutôt qu'MS se fout probablement pas mal de piquer du code libre, même du code du kernel Linux ou *BSD.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 0.
Oui, tu as tout à fait raison Ceci dit, récuperer du code n'est jamais chose aisée, et dans 99% des cas tu préfères le ré-écrire en repiquant simplement quelques infos. Donc même si MS pouvait repiquer ce qu'ils voulaient dans le libre, ils ne le ferait sans doute pas.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 0.
Ceci dit, il est certain que ça n'est pas à Linux que Windows à piqué ça.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 0.
Moi si, au moins depuis Win95, et sans doute 3.1. C'est un truc de base d'un desktop, les macs aussi font ça depuis des lustres.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 1.
En plus le login graphique existe depuis bien avant XP (NT l'avait déjà), et il y a des petits utilitaires qui refont les bureaux virtuels sous Win depuis longtemps. Quant au rappel des derniers programmes utilisés, ça c'est plutôt KDE ou Gnome qui l'ont repris à Win.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 10.
Faut pas réver non plus, à part quelques projets vraiment bons, si tu prends un truc sur freshmeat tu as de bonnes chances de tomber sur du code qui ne passerait pas les règles de qualité de n'importe quelle entreprise (y compris MS, qui a la réputation d'être assez strict de ce coté là, si difficile à admettre que ça le soit).
Ça n'est pas parce qu'il fait de l'open source que l'étudiant moyen qui fait son projet tout seul chez lui va se mettre à programmer comme un dieu. Même pire, comme il est souvent convaincu que faire de l'open source implique faire du bon code, il risque encore moins de se remettre en question.
[^] # Re: Conception du libre
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Le monde libre sur Apple. Évalué à 3.
Alors ça c'est un argument béton :-).
ce ne sont que des spéculations.
C'est déjà bien que tu t'en rendes compte :-).
[^] # Re: mon commentaire
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Un comparatif Linux - Windows pour l'utilisation personnelle. Évalué à 1.
Ça ne devrait pas, c'est la réalité (même si ça n'est pas vrai si on ne regarde que le free software, ça l'est globalement).
[^] # Re: Protection des licences
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de RMS. Évalué à 0.
Tu es sur ? Il me semble que non, et encore moins quand il s'agit de prouver une fraude.
[^] # Re: Une question
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Interview de RMS. Évalué à 1.
Une éventuelle possibilité oui, une garantie surement pas, hélas. C'est pas si simple de reprendre ou faire reprendre du code plus ou moins bien fait et documenté.
[^] # Re: re: délire ...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche HOWTO conversion de sa compagne à Linux. Évalué à 4.
"Enfin, celui qui a le plus de succès est le timide. Il les attendrit toutes. Par son mysticisme, les femmes veulent en connaitre plus et elles vont l'accoster."
[^] # Re: Ifrance
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche HOWTO conversion de sa compagne à Linux. Évalué à 8.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Interessant comme point de vue :-). Et quel est alors l'interêt d'en faire un composant ?
Pour moi permettre à d'autres applications qu'un traitement de texte d'afficher un document kwd ne sert à rien à part à compliquer les choses pour l'utilisateur débutant.
D'après mon expérience, ça ne semble pas être le cas.
Ça n'aide certainement pas à faire la distinction entre un gestionnaire de fichiers, un traitement de texte...
Mais pourquoi aurait-il à la faire ? Il n'y a aucune loi qui dit que cette distinction soit obligatoire, nécéssaire, ou même utile. L'utilisateur veut juste rédiger ses textes, ce genre de distinctions il s'en fout complètement.
Ceci dit les gens sont capables de choisir entre un portable Nokia ou Siemens
Mais contrairement aux toolkits, un portable siemens peut marcher sur n'importe quel réseau et appeller ou être appelé par n'importe quel portable. Tout ça est standardisé et compatible.
Pour un développeur, devoir choisir entre plusieurs toolkits implique qu'il va devoir passer du temps à évaluer chaque toolkit, puis à imposer à ses utilisateurs d'avoir la toolkit choisie installée et à jour. Pour du free, il va aussi imposer l'API a ceux qui veulent participer. Pour du commercial, à ses collaborateurs.
Dans le cas de Linux c'est pas trop un pb, toutes les distribs installent toutes les toolkits. Pour les autres Unix, y a que Motif et Athena en standard, et installer une toolkit n'est pas forcément trivial (faut souvent être root, avoir un accès à l'extérieur pour downloader l'archive, etc...). Windows n'a jamais posé ce pb à ses développeurs, et ça a été un avantage énorme.
Il n'y a qu'a voir le nombre de projets qui sont des portages d'un projet existant vers une autre toolkit. Est-ce vraiment interessant de faire ce genre de boulot ? Est-ce que le temps qu'on y consacre ne pourrait pas être mieux utilisé à améliorer l'appli de départ ? Et toi qui râle contre les trucs lourds, crois-tu qu'avoir plusieurs toolkits en mémoire (lance xterm, galeon, ddd et kword : 4 toolkits) soit une bonne chose ?
Pourquoi crois-tu que toutes les plateformes de dev récentes (BeOS, Java, .NET...) spécifient quasiment tout, y compris et surtout le graphisme ? L'industrie a compris la leçon.
Au moins sous Linux maintenant ça se décide entre GTK+ et Qt, les autres ont quasi disparu. Les choses s'améliorent.
Quant aux WM, là c'est pire : rien que faire comprendre le concept de window manager à un utilisateur de base, c'est ridicule. Et c'est aussi c'est une grosse source d'emmerdes pour les développeurs, avec des WMs qui sont plus ou moins IEEE compliant, les thèmes qui marchent plus ou moins bien, etc...
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Dans le cas d'une fonction simple et bien définie comme celle-ci, oui, sans doute.
Donc pour afficher un .doc, pas besoin d'un "composant" de traitement de texte, je veux juste qu'Abiword se lance, par exemple.
Je re-repête : un composant fait que ça revient au même. C'est même beaucoup plus leger qu'un lancement d'appli. KWord est juste une envoloppe minimale autour d'un composant, le même composant que lance Konqueror lorsque tu cliques sur un .kwd.
Puisque je veux avoir le choix, explique moi pourquoi il n'est pas important.
Parce que si tu ne l'avais pas, ça ne t'empècherait pas de travailler, et que d'ici quelques années tu ne te préoccupera sans doute plus de l'avoir.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Elles sont fausses dans l'autre sens aussi. Utile et bien programmé n'implique pas que le résultat soit leger, etc...
j'ai peut-être un peu plus de facilités pour juger ce qui est lourd parce qu'on ne peut pas faire autrement, et ce qui est lourd parce que c'est soit mal concu soit inutile.
Non. J'ai arreté d'avoir ce genre d'a priori sur des programmes après quelques années dans l'industrie, et m'être rendu compte que j'avais le plus souvent tord quand je jugeais qu'un programme était mal fait ou trop lourd. En pratique tu ne fais jamais de bons programmes, tu essaies de les faire le moins mauvais possible.
Ce que je voulais dire c'est que tes critères de jugement ne sont pas les mêmes que ceux du consommateur moyen, mais pas meilleurs (même plutôt moins bon, en fait). Il y a des choses qui sont importantes pour toi et qui indiffèrent le consommateur moyen (le choix d'une toolkit ou d'un WM), et inversement (l'intégration des softs).
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Tant mieux pour toi (c'est pas une critique, ou plutôt si, une critique des écoles d'infos :-).
Mais, c'est quoi l'image caricaturale que je m'en fais ?
Quelque chose comme :
Leger => utile et bien programmé
Lourd => inutile et mal programmé
Si tu comprends que ces deux assertions sont fausses, alors on est d'accord.
Donc en bon consommateur moyen je dis "c'est de la merde"
Non, tu n'es pas un consommateur "moyen", justement. Tu as certaines connaissances en informatique qui font que ton jugement est complètement différent de la moyenne. Tu ne prends pas les mêmes choses en considération.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Non, je dis juste que c'est comme ça que ça se passe dans la réalité, et que ça n'est pas forcément pour de mauvaises raisons comme tu sembles le penser (les développeurs ne font pas de la merde avec des surcouches inutiles).
Il ne faut pas non plus vouloir écouter de la musique avec ce que l'on a, mais acheter un lecteur.
Non. Je dis que tu aura probablement un meilleurs résultat comme ça. Enfin bon, sur ce plan là je concède que le mp3 a quelques avantages sur le CD normal, si ça peut te faire plaisir :-).
Et ailleurs tu me dis que je ne devrais pas vouloir avoir le choix d'un WM ou d'un toolkit.
Non, je dis que ce choix n'est pas important. Et même que ce choix a beaucoup handicappé Unix sur le desktop.
Relis mes posts. Je ne te dis pas "il faut faire ci ou ça", je te dis juste comment les choses se passent en dehors de ton école d'info, et que le monde du logiciel, libre ou proprietaire, est bien plus complexe que l'image caricaturale que tu t'en fais.
Mais ne te fais aucun souci, tu découvrira tout ça par toi-même plus tard, on est tous passé par là. Et je sais que ça t'agace profondément qu'on te le dise, ça m'agaçait aussi. Mais maintenant avec un peu plus d'expérience, je suis bien forcé de reconnaitre que ceux qui me le disaient avait raison.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 3.
Globalement non, bien sur, mais quand même un peu. Quand tu obtiens un résultat acceptable en 2 jours de dev, t'as pas forcément envie de passer 10 jours de plus pour un gain hypothétique. Il faut bien se dire qu'optimiser un truc, c'est un boulot sans nom. D'abord, tu ne sais quasiment jamais où tu perds le plus en perfs. N'importe quel developpeur un peu expérimenté te dira que les parties lentes de ton code ne sont jamais celles auxquelles tu t'attends. Il faut profiler ton soft pour être sur de là où tu dois chercher à améliorer les perfs.
Ensuite, dans l'optimisation tu vas obligatoirement casser quelque chose. Statistiquement, tu es presque sur d'introduire des bugs. Et si par "optimisation" tu veux dire "ré-écrire avec un langage plus rapide", là c'est pire.
Mais pour ce qui est de GTK, tu es bien placé pour le savoir, ça reste objet, léger et simple d'utilisation.
Au contraire, je suis bien placé pour savoir que c'est à l'objet ce que la mobylette est à la voiture, très lourd, et pas simple du tout à utiliser. Mais dès que tu fais de l'objet sans que ce soit supporté au niveau du langage (ie avec un langage pas objet, C ou un autre), tu vas arriver à ça. Ceci dit oui, GTK+ reste plus sympa à utiliser que Motif, mais globablement ça reste un truc assez horrible. Tu passes ton temps à faire le boulot du compilateur avec des casts à tout va et la dérivation à la main.
Le côté boite noire fait que tu n'as pas vraiment à savoir ce que fait l'objet en interne mais pour l'utiliser correctement, tu dois connaitre quand même son fonctionnement interne.
Si c'est le cas, c'est que l'objet a été mal designé. Malheureusement en pratique c'est souvent vrai, mais on progresse. Il a fallu du temps pour qu'on comprenne bien comment faire de l'objet. Sur la question, je te conseille le chapitre d'intro du fameux "Design Patterns".
alors qu'on peut faire mieux sans cet amas de couches.
Oui, mais là encore au prix d'un temps de développement accru. Et encore, ça n'est pas évident que tu va gagner en perfs. Pour reprendre l'exemple de l'OO en C vs. un langage objet comme C++ : un compilo C qui voit un appel à une fonction à travers une table (pour émuler une méthode virtuelle) traduit ça tel quel, parce qu'il ne sait pas ce que c'est. Un compilo C++ sait ce qu'est une méthode virtuelle et peut le traduire de manière bien plus efficace.
C'est un peu comme si tu dictes une ordonnance médicale à quelqu'un qui n'y connait rien : il va noter scrupuleusement chaque mot, parce qu'il ne comprend pas de quoi ça parle. Si tu la donnes à un pharmacien, il va comprendre de quoi il s'agit, et par exemple pouvoir te dire que tel médicament est équivalent à tel autre qui coute moins cher, ou que ces deux médicaments là peuvent être remplacé par un seul, etc...
Un autre exemple c'est que tu peux facilement exprimer des choses plus efficaces. Par exemple, les classes de listes ou de string etc... de Qt (QList, QString, QArray...) sont bien plus efficaces qu'un équivalent en C parce qu'elle savent gerer leur données internes avec des compteurs de references, faire du Copy On Write, etc... Donc un truc du genre :
QString a = "blah"; // a copie "blah"
QString b = a; // b reference le char* interne de a
// donc pas de copie
b[0] = "c"; // b cree automatiquement sa propre copie de "blah" et la modifie
C'est impossible d'avoir ce niveau de controle en C, ça serait infernal à coder et à debugger. Donc un QString est plus gros qu'un simple char* (pas de beaucoup, quelques octets de plus), mais son utilisation est en moyenne beaucoup plus efficace.
Augmenter les couches d'abstraction coute un peu en perfs, mais t'en fait gagner beaucoup aussi. Il faut juste le temps que les compilos s'améliorent.
ce que tu gagnes en temps de developpement, tu le fais perdre largement en infrastructures
Mais le temps de développement coute en général plus cher que les infrastructures. En plus il y a l'utilisation ensuite.
Si tu fais un serveur en Java au lieu de C++, tu vas le finir 3 fois plus vite (c'est le gain généralement constaté je crois) et le résultat sera plus fiable qu'en C++ (Java a sa part d'emmerdes, mais globalement c'est ça). Si ton serveur fait un boulot un tant soit peu crucial et donc que chaque fois qu'il tombe ça se traduit par une perte d'argent (les gens peuvent plus bosser, les clients peuvent plus contacter le site web, etc...), le coup des machines est très vite amorti.
[^] # Re: Un peu comme MS-Windows 1
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 2.
Oui, mais si ça augmente les délais de développement ça n'a aucun interêt. Le développement coute plus cher que le hard, et en général quand on optimise on commence surtout par introduire des bugs et casser des features. C'est pour ça que Java marche bien sur les serveurs : c'est rapide à developper, et pour combler la perte en perfs par rapport à C++ tu prends de plus grosses machines. Au final, ça coute beaucoup moins cher.
A mon avis, il est des choses qu'on ne devrait pas considérer comme normales (telle la prog objet)
Bien sur que si, au contraire. A part pour du code trivial, l'objet est toujours interessant. Dès que tu as des structures de données et des fonctions qui travaillent dessus, tu peux faire de l'objet. Ça recouvre la majorité des cas.
Il me semble qu'une approche composants / légo[...]
Là non, je suis d'accord, c'est surtout utile sur le desktop.
tu te retrouves avec une appli comme le gestionnaire de fichier de gnome, avec 150000 appels à la même ressource.
Gnome est un mauvais exemple. Ils ont voulu faire de l'objet en C en croyant que la programmation objet c'est juste du sucre syntaxique, ils le payent. Justement, c'est en voulant faire leger qu'ils sont arrivé à un truc plus lourd que KDE.
[^] # Re: alignement des données
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Par ailleurs, je pense qu'à un certain niveau d'optimisation il doit pouvoir réordonner les membres lui-même, mais ça peut être source de jolis bug si tu ne compiles pas tout avec le meme niveau d'optim. En pratique c'est même le genre d'optimisation que je ne voudrais pas faire : gain négligeable au runtime, énormes pertes de temps potentielles au dév.
[^] # Re: Pourquoi le soft est cher ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Ces "nouveaux" gestionnaires de fenêtres. Évalué à 1.
Pardon, je clarifie : il est normal que les vieux logiciels propriétaires ne soient plus maintenus, ça coute trop cher et ça n'est pas rentable. Pour le libre, si il y en a que ça amuse de maintenir des vieux trucs c'est bien, ça peut être utile à quelques uns, mais c'est moins interessant que d'avancer. Quant à l'idée de faire des "nouveaux vieux trucs" comme Ion, alors là oui c'est complètement inutile. Mais bon, dans le libre on peut se faire plaisir, si c'est le cas pour l'auteur de Ion, très bien. Je connais bien Chris Cannam, l'auteur de wmx dont on parle plus bas, puisque je développe Rosegarden avec lui. Il a fait ça pour le plaisir aussi, il y a longtemps, et il n'ira jamais dire que c'est la seule bonne façon de faire un window manager parce qu'il ne faut pas faire de gadgets.
Mais sinon, qu'un logiciel ne soit plus maintenu, propriétaire ou pas, n'implique pas qu'il devienne du jour au lendemain inutile. Tant que ça marche, autant le garder.
Après, quand je dis "vieux logiciel", je parle d'un truc qui n'évolue plus et que pratiquement plus personne n'utilise. Ça n'est pas le cas de Window Maker par exemple. C'est pas simplement une question de nombre d'années d'existence.
Dans le même ordre d'idées, si on arrete de développer un traitement de texte (disons Ted que j'aime bien), au bout d'un an il sera incapable d'ouvrir des documents actuels.
Tu veux dire si on arrête de maintenir les filtres d'import... Oui, c'est vrai, mais je ne vois pas l'interêt d'essayer d'importer du Word récent dans un tdt tellement ancien qu'il ne saurait pas manipuler des images incluses dans le texte par exemple (je ne sais pas si Ted sait faire ça, je parle en général).
Le jour (s'il arrive) où tout le monde utilisera IPv6, les vieilles machines auront aussi besoin de savoir ce que c'est.
Pas si ça coute moins cher de les remplacer, ce qui sera très probablement le cas (sauf celles tournant sous Linux/*BSD, et encore... si le noyeau est devenu définitivement trop gros pour tourner sur un 486 ou un pentium, ben tant pis, c'est vraiment pas grave).
HTTP2 est un bon contre-exemple aussi : Netscape3 ou Mosaic sont morts, remplacés par NS4, 6, MSIE, Konq, etc... qui nécéssitent bien plus de CPU. Netscape ne va pas exhumer NS3 pour y ajouter un protocole qui ne servira à rien puisque de toute façon le browser est déjà obsolète.