HappyPeng a écrit 324 commentaires

Moi je ne suis pas un adepte de son "business model"... On en revient presque à l'époque du shareware, c'est un peu triste.

Passez-moi le discours sur "les développeurs ont besoin de vivre", "il a le droit d'être rémunéré pour son travail" et tout ce qui a déjà été dit pour les chanteurs et autres.

Je parle du concept même de logiciel libre : la liberté ne se soumet à aucun chantage financier selon moi.

Je suis pas certain que GIT soit un excellent exemple ...

C'est un modèle marketing qui roule, entre Ubuntu qui fait sa publicité gratuite via les LUGs et le livre qui doit être republié et racheté à chaque version :-)

C'est absolument faux, ça n'est pas parce que c'est du logiciel libre qu'il faut faire n'importe quoi.

Le prétexte est le suivant : puisque c'est libre, vous n'avez qu'à adapter votre driver puisque vous pouvez le faire. Simplement c'est abuser des ressources dont nous disposons : les développeurs n'ont pas que ça à faire, déjà souvent de développer le logiciel ; alors que là on leur demande en plus de cesser toute innovation pour faire du simple portage à chaque fois qu'une version mineure du noyau sort. Quel gaspillage ! Et aussi, quel enfer pour l'utilisateur ...

Partout on ne parle que de formats standards, d'API standards, d'interfaces définies, versionnées et stables. Le kernel ne fait _aucune_ exception. GNOME par exemple ne changerait pas ses interfaces tous les quatre matins en disant "les développeurs peuvent adapter leurs applications".

C'est tout simplement absurde.

Quand à l'argument de la rapidité de développement, certes. C'est de la rapidité de développement sans phase de conception et de réflexion préalable, on écrit du code spaghetti, on avance par patch mineur sur patch mineur : ça n'est pas non plus un bon prétexte. Des interfaces bien conçues doivent pouvoir durer plus de deux semaines. (POSIX dure bien des années.)

Cette solution ne passe pas le test du dissident chinois.

Il y a effectivement un truc que je ne comprends pas.

De nos jours on peut toujours ripper nos DVD dans un format tout à fait banal (container AVI ou OGM et codecs quelconques), n'intégrant aucune forme de DRM.

Comment alors distinguer mon passionnant film de vacances que je souhaite partager avec le monde entier et un film protégé par ladite loi, avec un système de DRM ? Comment protéger des oeuvres par DRM sans alors interdire tout oeuvre qui ne soit pas protégée par un DRM ?

Cette loi obligerait donc quasiment à DRM-iser tout le contenu, y compris ce qui est libre, et à ne pas permettre aux humains lambda de le faire (sinon ils pourraient marquer comme libre un contenu hautement protégé).

Conclusion : pas de possibilité de partager des créations personnelles par le moyen du peer-to-peer avec une telle loi.

Même pour Java, même pour C#, ceci aurait un impact lourd sur les performances de l'ensemble. Et du Python même avec psyco ça n'est pas une foudre de guerre, ça ne fait qu'améliorer un peu la rapidité.

A mon avis ce sont des faux problèmes, il vaut mieux avoir une bonne base écrit dans un langage "généraliste" C/C++/Objective-C et choisir le langage le plus adapté à son application ensuite.

Pour le coup (Java, Python) on peut craindre d'énormes problèmes de performances si l'ensemble des applications venaient à être réécrites dans ces langages.

Il n'y a pas de raison pour que du C++ soit plus lent que du C avec des GObjects. Même chose pour l'Objective-C dans une certaine mesure.

Il faudrait arrêter de tout ramener à la performance ; dans le domaine du desktop il n'y a pas _que_ ça qui compte.

En train de répéter les mêmes fantasmes avec .NET alors que cela a déjà été fait avec Lisp avant Java.

Le postulat "Coder c'est compliqué, pour que les utilisateurs fassent des programmes il faudrait que ça soit sans code" mérite d'être discuté. Ecrire du code peut s'apprendre de façon simple, comme de nombreuses connaissances ; et il a déjà existé des projets d'environnement de programmation pour les enfants (voir Smalltalk et ce/ceux qui tournent autour).

Le problème est dans ce que l'on apprend à l'école ou dans ce que l'on est prêt à apprendre ensuite ; peut-être également le fait que la plupart des gens pensent que maintenant avec l'informatique apprendre n'a plus aucun sens, ce qui est une erreur ...

Vu le nombre de projets écrits en C/C++ je pense qu'on peut quand même espérer trouver des développeurs qui savent écrire correctement des programmes qui marchent, sont performants et bien écrits dans ces langages (et la gestion mémoire n'y est pas si dramatique et a même ses avantages, ne nous lançons pas dans un bas troll garbage collector).

Le fait qu'un projet soit codé dans un langage "simple d'abord" n'est pas une avancée en soit, car il est tout de même assez rare que les gens qui apprennent un langage, python, parce qu'il est simple d'abord écrivent le code aussi bien que ceux qui ont l'habitude du C, par exemple.

Enfin, Tom Lord a réussi à écrire ce qui est pour moi le meilleur SCM du moment sans être financé ni soutenu par une grande équipe de développement (qu'il l'ait refusée ou non), donc le soutien par Canonical, ça m'est quand même relativement égal.

Tla (et baz) n'ont pas de rapport avec bazaar-ng.

Aujourd'hui personne n'utilise encore bazaar-ng (pas plus que tla 2.0) et ce n'est pas un projet fini.

J'ai également du mal à voir en quoi le fait que bazaar-ng et mercurial soient écrits en python constitue un avantage.

*BLONK*

Les pseudo-objets ça n'existe pas.

Une entreprise a rarement des buts totalement humanistes.

Il ne suffit pas de le dire pour que cela soit vrai.

Exemples typiques de problèmes : tu avais des partitions en ISO-8859-1(5) (un vrai truc, de l'ext2/3, du XFS, du ReiserFS ...), quelqu'un te file une clé USB avec des noms de fichier en ISO-8859-1(5) ...

Essaie.

Sauf qu'il n'existe pas qu'un format de document, comme il n'existe pas qu'un encoding. Ce qui est important c'est qu'ils soient normalisés. Pas que tout le monde utilise le même.

Le plus possible préciser les encodings, comme c'est le cas pour XML.

C'est facile de dire que tout le monde doit utiliser le même encoding, presque autant que "tout le monde devrait utiliser le même OS" ou "tout le monde devrait utiliser le même système de fichiers".

Je continue de penser qu'il est absolument néfaste de forcer un encoding/charset dans une application, ou, encore plus fortement, dans une distribution.

En effet, aujourd'hui c'est UTF-8. Mais on sait qu'UTF-8 n'est pas la panacée, et on peut imaginer qu'un jour il faudra passer à UTF-16, voir d'autres encodings/charsets. Recommencera-t-on alors le même cirque ? Si l'on continue à faire comme à présent avec l'UTF-8, certainement. Le passage se fera dans la douleur, les bugs et les noms de fichiers qui ne se lisent pas.

Les applications GNOME sont parfaitement indépendantes de l'encoding/charset, comme le sont (ou devraient l'être, mais souvent c'est bien le cas) toutes les applications composant une distribution. Pourquoi alors forcer absolument l'UTF-8 ?

Il est toujours plus simple de proposer une option par défaut mais cela ne devrait pas empêcher d'en proposer d'autres, dans un menu "avancé", une ligne de commande ou autres ...

Je pense qu'il est totalement hors de propos de parler d'"encoding du futur" ou autres : cela n'a aucun sens (il y a des encodings plus "universels" ou "futuristes" qu'UTF-8, dont certains déjà utilisés comme UTF-16), et c'est une histoire de choix auquel les utilisateurs ne devraient pas être soumis.

Par exemple, et je sais qu'il est provoquant, on ne retire pas le support du .DOC d'OpenOffice.org en disant que "de toute façon, .DOC c'est mal".

Pas ou, une variable a remplacé l'autre, normalement.

Par contre il faut bien noter que le rendu CSS ne se limite pas à (X)HTML.

Je n'ai pas dit que ce n'était pas Gecko qui faisait le rendu ... c'est bien le cas, mais je souligne la nécessité d'avoir une autre solution que d'ouvrir le document dans Mozilla et de cliquer sur "Imprimer", ce qui est malpratique dans de nombreux cas, lorsque l'on traite plusieurs documents, lorsque l'on veut faire ça en sortie d'une autre application, etc.

Comme je viens de le dire, Mozilla a fondamentalement une approche par composants (d'ou XPCOM, son framework de composants) ; et il est possible de faire tout cela grâce à des composants de Mozilla : regardez notamment tout ce qu'il est possible de faire grâce à une application en JavaScript depuis Mozilla.

Cependant, ce qu'il est relativemet difficile de faire, c'est d'utiliser des composants de Mozilla depuis une application "autre", c'est-à-dire qui n'est pas construite sur la base de Mozilla comme le sont Firefox, Thunderbird et autres. D'ou les manques soulignés.

FO est un langage de description de page relativement complet, en tout cas plus complet que CSS dans le domaine de la mise en page destinée au papier.

Après, reste à savoir si fop est une implémentation défectueuse ... mais bon, pour m'en être déjà servi, je ne pense pas que ce rendu soit spécialement "primitif" à condition de disposer d'une feuille XSL bien écrite.