Je connais Guernica et son histoire, je n'ai pas choisi mon exemple au hasard ;-)
Guernica est le type même de l'oeuvre qui est poteuse d'un sens politique et moral fort, ce qui oblige à un certain respect du contexte de l'oeuvre et de son intégrité. L'artiste s'est inspiré d'un fait réel, mais il lui donne du sens ce qu'aucun code ne contient et ne contiendra jamais et ce qui rend heutement dangereuse l'application de licences libres à l'Art.

[ Répondre ]

En relisant la traduction, voilà une phrase qui résume bien ce que j'esayais de dire

moi je pense que la musique est une création destinée à communiquer des idées sous la forme de symboles sonores; et mon ambition première et de communiquer ces idées aux autres.

je pense pas que le code soit "une création destinée à communiquer des idées sous la forme de symboles cé-plus-plus-esque" ;) et c'est là tout la différence.

Au passage la différence vaut aussi entre une doc tecnhique qu'on passera sous FDL et un roman ou un essai pour lequel ça me semble peu approprié

[ Répondre ]

Comparer Guernica et Emacs n'a pas vraiment de sens AMHA, appliquer à l'un les principes que l'on applique à l'autre en a encore moins.
Utiliser (et surtout réutiliser) un tableau comme Guernica IMPOSE de respecter la pensée, le cri qui est derrière et c'est en bonne partie à cela qu'il faut penser.
Du code reste du code, il importe de bien comprendre que des concepts comme "No Discrimination Against Fields of Endeavor." (Debian Guidelines) ne DOIVENT pas être appliquées à une oeuvre artistique: il est le droit absolu d'un artiste de refuser l'usage de son Oeuvre dans le cadre un meeting FN ou pire sa réutilisation déformée dans un sens opposé à celui qu'il veut donner. L'Art (et le Jazz particulièrement) est porterur d'un sens bien plus grand que le code. Restons modeste ;-)

[ Répondre ]

Ouais enfin appliquer la notion de libre à l'Art est TRES problématique, l'artiste a un droit au respect de son oeuvre de sa perspective, de ses idées.
C'est pas comme un code qui est juste utilitaire.
Du reste, la démarche reste hyper intéressante, faut arrêter l'intégrisme...

[ Répondre ]

On va pas recommencer le bazar qu'il y avait eu pour le 4.2 :o
On laisse Branden bosser.
Ça sortira quand ca sera prêt :p

[ Répondre ]

Une knoppix en DVD-R, le rêve
à la base c'est sans doute faisable par n'importe qui vu l'aide fournie pour customiser la Knoppix, le problème, c'est de l'héberger après.
Sur mon ADSL, ca va être dur ;-)

[ Répondre ]

> Il fonctionnera avec les architectures Itanium et IA 32.

et le x86-64 hmmmm ?

[ Répondre ]

Mais ca ne favorise pas le support de leur soft, donc ca déssert au final le soft vendu.

[ Répondre ]

Oui, je pense qu'il s'agit de MSN/Windows Messgenger que je suis AUSSI obligé de vire à chaque fois et ca c'est SUPER CHIANT !

Pour ceux qui ne connaissent pas: http://www.xp-antispy.de/(...) le fait très bien (entre autres choses): à installer juste après XP

[ Répondre ]

Ce n'est pas aussi simple que cela. Si il n'y a qu'un seul moteur, on est loin de l'esprit du libre, on a a faire a une situation de monopole et la norme devient indissociable du produit.

Pas forcément si justement le respect de la norme est total.
Je parlais bien dans cette phrase de ce que tu appelles:

- Respect strict : tout ce qui n'est pas la norme ne marche pas, tout ce qui est la norme marche.

C'est du reste de ce que fait Gecko non ? Je me souviens de deux ou trois cas de code porc toléré par IE et refusé par Mozilla alors qu'il aurait été simple de l'accepter quand même. Mais le refuser c'est promouvoir la norme.
En ce sens, sa domination ne pose àmes yeux pas de problème, car elle n'a pas les conséquence négatives de la domination d'un moteur comme celui d'IE.
Je suis assez gêné par ta conception en META du HTML. Tes "zigouigoui rigolos derriere", sont dans la norme ou pas ? Su oui, tous les moteurs doivent les supporter, car un moteur doit supporte la norme, toute la norme. Sinon, alors personne ne doit les reconnaitre car un moteur doit respecter la norme, rien que la norme. Ouvrir la porte à des extensions qui ne seraient pas couvertes par la normes, c'est inciter à utiliser le moteur dominant. Quand une fonction non-indispensable sur un site manque aujourd'hui à un navigateur non-IE, le réflexe logique de 99% des users est de retourner/rester sous IE.
J'exclus les navigateurs spéciaux genre Lynx ou ceux des PDA du champ du § précédent.


A mon sens Gecko est plus un outil oriente utilisateur final, qu'une bibliotheque. Mais tant bien meme ce ne serait qu'une bibliotheque ce que tu dis n'es vrai que dans le cas ou le HTML est une norme
- 1) totalement implementee (ie toutes les fonctions HTML sont supportees)
- 2) figee (ie pas d'ajout de fonctions a venir).

Je concois mal le premier point par contre je suis coincé pour le second ;-)
J'ai, cela dit, du mal à imaginer une fonction qui ne serait pas implémentable dans un moteur de rendu HTML pour des raisons d'architecture graves, mais je suis une bille en prog et en plus je connais mal l'architecture de ce genre de choses, donc je em trompe sans doute.

KHTML a l'air de vouloir faire un support optimise quite a ce qu'il soit restreind, alors que Mozilla cherche plutot un support complet au detriement de l'optimisation.
Il me semblait avoir lu (faut vraiment que je note mes sources moi) que les devs de mozz avaient d'abord optimisé le support de lanorme et la compatibilité et que maintenant ils cherchaient À optimiser.
Hors les cas particuliers, il me parait dangereux de ne pas implémenter toute la norme, ca la vide un peu de son sens :-/

Bref, en fait, ptet que j'ai tort dans ma conception d'un moteur de rendu HTML, trop strict peut-être.

[ Répondre ]

Oui et non. Il est vrai que si il n'y a que trois ou quatres moteurs sur le web, tu peux envisager de faire des codes specifique pour chacun d'entre eux, ou te limiter au niveau des fonctions pour sortir une page qui passe partout. Mais ca demande du temps, pas mal de tests et une pletore de code javascript pour ne pas se planter.
[...]
A l'inverse si il y a un bon nombre de navigateurs differents bases sur des moteurs independant, il y aura obligation d'uniformisation. Cela donnera beaucoup plus de poid au W3C (et beaucoup plus de travail aussi) et la notion de "site optimise pour X" disparaitra.

Bah bof parce que justement la norme ne fixe pas tous.
Il suffit de se rappeller le problème Hotmail/Mozilla/Opera: une page conforme à la norme passait sous Gecko et pas sous Opera pour une affaire marge négative tolérée par la norme. Tu vois, j'ai perso un forum avec des amis qui tourne sous un bazar proprio sous nux/PHP/MySQL. Quand tu causes au webmaster et que tu demandes une modif pour rendre le site plus W3C compliant, tu as du poids si la modif concerne "bcp" de monde. Si en une modif il s'assure la compatibilité Mozilla/Phoenix/Galeon sous Win32, Linux, MacOS, etc., il sera enclin à la faire. Si il doit faire une modif pour chaque moteur, ça va le saouler et ça se comprend en un sens.
Bien sur un tel moteur unique ou quasi-unique se doit d'être respectueux de la norme et intransigeant sur celle-ci. Rigoureux pour ne pas introduire d'incompatibilités (c'est le minimum) et intansigeant pour ne pas laisser se prendre de mauvaises habitudes et contraindre à respecter la norme.


Concernant Gecko,KHTML et consors il est absolument vital que ces projets coexistent. Contrairement a ce que tu as l'air de penser deux groupes de devellopement qui travaillent en parallele sont nettement plus efficace qu'un seul groupe de taille double. C'est un probleme bien connu en info le probleme du macon (aussi connu sous le nom du theoreme du trou) : Si un macon peut faire un mur en 1 heure, alors 3600 macons peuvent faire un mur en 1 seconde.

Jolie métaphore je la resorirais car je en la connaissais pas ;-)
Mais j'ai plutôt l'impression qu'on est dans cette situation: on veut faire un mur d'un mètre et on a 2 maçons. Au lieu de faire un mur ensemble, ils font chacun le leur, avec des techniques différentes qui ont leur avantages et leur inconvénient, etc. Bilan: on deux beaux murs divers et tout mais ... de 70 cm :-/ (plutot de 90 et 50 mais ne chipotons pas ;-). Note au passage qu'en cumulé on a plus de longueur de mur, on a en plus une grand diversité, des gens pourraint comparer nos murs et tout mais bon, on a pas notre mur de 1 mètre.
Encore une fois, la comparaison KDE/Gnome me semble bizzare: un WM c'est comme un shell, il y en a plusieurs, c'est normal, ça a toujours été. Gecko pour moi c'est plus la libjpeg, je vois pas l'intérêt de faire 15 versions différente d'un truc utilitaire. KDE/Gnome ou bash/zsh/ksh ya des différences de look & feel, d'approche, etc. La libjpeg, tant qu'elle fait son travail, on est content et c'est le prog qui l'exploite qui est important. C'est pourquoi je considère Galeon comme très logique: il intègre un truc utilitaire (Gecko) en se positionnant différement de Mozilla.
Et sur Gnome/KDE, je suis pas sur que les débuts difficile à se tirer dans les pattes et les conflits qui ne demandent qu'a resurgir au moindre prétexte (voir KDE/RedHat) ne soient pas salement nuisibles. Tu ajoutes à ça la division des efforts, je suis pas convaincu. Maintenant qu'on en est là on fait avec. Surtout que ça sous-tend la concurence gtk/QT qui elle a un sans par la différence d'approche (il me semble).

[ Répondre ]

Ah bah voilà une info intéressante, grand merci à toi, j'essaye

[ Répondre ]

Encore une fois, je n'ai pas de solution et je ne voudrais surtout pas imposer quoi que ce soit à qui que ce soit.
Mais je trouve dommage que des jours.hommes soient investi dans un projet à l'utilité discutable quand il aurait tant À faire À coté.
Mais chacun fait ce qu'il veut.
juste un point sur GIMP: perso je dois dire que j'ai du mal avec, je comprendrais parfaitement par exemple qu'on veuille refaire un autre soft parce qu'on aime pas son ergonomie ou un truc du genre. J'ai plus de mal à transposer ca à Gecko. Mias c'est peut-être par méconnaissance: je n'ai pas la science infuse ;-)

[ Répondre ]

Même au niveau du rendu il peut y avoir des différences car les normes ne sont pas toujours précises et laissent une marge de manoeuvre pour implémenter telle ou telle propriété.

raison de plus pour limiter le nombre de moteurs non ? Ça ficilite le boulot des webmasters.

C'est en partie pour cela qu'Apple a préféré KHTML à Gecko lors du développement de Safari.

il me semblait avoir lu (faudrait encore chercher le source) que le problème était lié en bonne partie au manque d'optimisationde Gecko car les devs agissaient "par priorité" successives. Sans doute les gens de KHTML auraient-ils pu aider à cela.
Peut-être pas.

[ Répondre ]

La raison de dépard de l'existence de Gnome était un pb de licence ;-)
aujourd'hui, les approches des deux sont différentes et constituent donc un enrichissement pour le Libre, mais j'ai du mal à voir l'enrichissement sur un moteur de rendu.
Bien sur il me s'agit pas d'interdire, je me vois mal aller leur casser la gueule pour convaincre de passer à Gecko ;-) Je constate juste qu'il y a une division regrettable :-/ Je ne leur impose rien, je constate dans un soupir que les choses pourraient être mieux.

[ Répondre ]

Il y a diversité et diversité
Contrairement a ce que semble croire ceux qui se sont acharnés sur le [-] je ne suis pas un fou de l'uniformisation.
Entre KDE et Gnome il y a de vraies différences de fond dans l'approche, dès lors chacun choisit, certes.
entre Mozilla mail, KMail, Evolution, etc. pareil.
Mais pour un moteur de rendu HTML, je suis perplexe, je l'avoue.
Un moteur de rendu HTML a pour moi un but et un seul: rendre le mieux possible et le plus vite possible du HTML en respectant les normes du W3C. Gecko le fait et il est sous GPL.
Attention: je ne parle pas de Mozilla: on a le droit de ne pas aimer son interface, sa lourdeur, etc. Mais si les devs de KHTML avaient travaillé à améliorer Gecko, au lieu de deux moteurs ayant exactement le même but, nous en aurions un meilleur que le meilleur des deux prix indépendamment.
Il ne faut pas se leurer: le nombre de développeurs du Libre libre n'est pas infini aussi je trouve souvent dommage de perdre du "potentiel" dans des projets qui n'ont pas vraiment de sens alors que les devs pourraient d'unir.
Je pense la même chose de Koffice (ou Gnome-Office, hein, pas de troll): nous avons tant besoin d'une suite bureautique au niveau de MS Office que cela me semble une perte de temps, mais encore là, on trouve un sens puisque peut-être certains détestent OO.o et préfèreront KOffice. Pour KHTML je vois pas :-/

Un dernier point: au-delà de ce cas particulier, je trouve personnellement regrettable cette volonté d’intégration à tout crin. Je me souviens avoir lu sur DLFP un commentaire au sujet de la RH8 qui avait viré Konqueror: en gros ça disait "Konqueror est à 99% intégré à KDE: quand je me suis tapé les 3 heures de chargement de KDE, c’est pour que Konqueor soit utilisable tout de suite." Ca m’a tragiquement rappelé les "techniquement indissociable" de MS sur IE. Sous win, je râle parce que je suis obligé de charger IE en mémoire alors que je préfère Mozilla et finalement par un atroce coup du destin je finis avec la même chose sous KDE. Tragique non ? Qu’on me comprenne je ne dis pas "KDE c’est Windows" (un point Godwindows comme le suggérait quelqu’un sur un autre commentaire sur RH8), mais juste qu’on m’a toujours dit que la diversité c’était bien et que tout fusionner en un programme géant c’est mal (un avis similaire avait été posté à propos de l’intégration de calendar dans Mozilla: faudrait retrouver.) Il est inutile de se disperser à l’excès et il est regrettable de trop unifier, AMHA :-/

[ Répondre ]

10 minutes ?
en boot depuis le CD, la knoppix boot super vite chez moi.
et il est de fait que sans la moindre intervention de ma part, elle a tout reconnu

[ Répondre ]

juste un gros manchot (comme Tux qui n'est pas un pingouin, il est toujours bon de le rappeler) qui a du mal avec les claviers allemands ;-)

[ Répondre ]