Il ne supporteront pas le h264 car ceux qui reprennent le code de Firefox (distributions Linux, Flock, etc.) ne disposeraient pas eux même de la licence et donc ne pourraient pas reprendre le code tel quel.
De plus, la MoFo soutient les standards ouverts sur Internet, donc pousser h264 serait un manquement a leurs idéaux.
En gros, le problème de saccades pour les animations vient du Garbage Collector. En réduisant la pause due au GC, cela devrait améliorer les performances. Et ceci sans compter les améliorations sur le moteur Javascript lui même, comme l'amélioration de l'accès aux propriétés du DOM que tu dois utiliser dans ton code.
C'est écrit dans la dépêche: comme les systèmes sont de plus en plus multicore, le père continue a s'exécuter sur le même core et le fils s'en va être exécuté sur un autre core.
Ainsi il n'y a pas de changement de contexte pour le père qui peut s'exécuter tranquillement et le fils peut s'exécuter en parallèle.
Néanmoins le problème que tu soulèves a propos des copies inutiles de pages mémoires me semble toujours être la. Est ce qu'il s'agit vraiment d'un gros problème? Peut être pas, d'où l'intérêt du patch en question.
Je ne viens pas de SSII, mais je trouve que ces tutoriels comble un besoin différent du site du zéro: aider quelqu'un a commencer sur le sujet avec jusque ce qu'il a besoin pour pouvoir avancer au lieu d'être perdu avec beaucoup de choses a lire / savoir.
Bien sur, en cas de problèmes, et bien ce ne sera pas si facile puisqu'il manquera les bases.
Effectivement, les tutoriels sont perfectibles. D'où l'intérêt que ce soit libre! Il ne leur reste plus qu'a préciser la licence et a l'indiquer sur les pages et a vraiment s'ouvrir en acceptant les contributions de l'extérieur.
Certes mais les processus bouffent plus de ressources que les threads.
Apache httpd était historiquement base sur des processus, puis ils sont passés sur un modèle ou ils utilisent des threads.
De plus, il y a des comparatifs sur la gestion mémoire. Plus il y a d'onglets ouverts, plus Google Chrome consomme de mémoire que Firefox, mais alors vraiment beaucoup plus.
Alors il y effectivement des avantages, mais il y a aussi des inconvénients.
J'avais lu la proposition d'implémentation du projet ajoutant le reverse debugging à GCC. Autant que je me souvienne, le debugger faisait effectivement des snapshots du programme à intervalle régulier, et il se rappelait également autant que possible des entrées-sorties (entrée standard, socket TCP/IP, interrupts, ...). Lorsque l'utilisateur faisait un pas en arrière, le programme était exécuté à nouveau depuis le snapshot jusqu'au point d'arrêt.
C'était l'approche choisie.
Quand à lui, l'omniscient debugger pour Java enregistre des informations lors de l'exécution du programme. Et lorsque l'on fait un pas en arrière, il consulte juste ce qui avait été enregistré, et utilise juste cette mémoire pour revenir en arrière. Il était possible de paramétrer la quantité de données que le debugger peut utiliser pour se rappeler les états précédents.
Je pense que l'approche 1 convient à un programme bas niveau alors que l'approche 2 convient à un programme plus haut niveau. Le programme bas niveau doit se rappeler plus de choses.
Bah tu sais ce qu'on dit sur linuxfr.org, si tu peux faire mieux tout le monde sera content et tu auras toute la reconnaissance de plein de gens. Maintenant ça passe par la case code...
Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile. Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Ce qui n'a rien a voir avec «intensivement testé».
Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
Pour un truc «intensivement testé» et donc «deverminé», c'est un peu opposé a «supporte meme pas les threads».
Je vois pas le rapport.
Trop génial : un lock global.
Ah non, y'a pas a dire, trop top génial gc... completement testé.
Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
Ahem Python a aussi un lock global. Linux, FreeBSD avaient un lock global jusqu'à récemment. Pourtant ils étaient déjà utilisé en production mais pas finalisés selon toi? Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
M'enfin si ça t'amuse continue a critiquer dans le vent.
Pourquoi ne pas utiliser au mieux les forces de ces compilateurs?
A priori, si ton projet le supporte, tu pourrais utiliser LLVM pour développer (cycle code / compile / éxécution rapide), et utiliser GCC pour générer les binaires pour les équipes de test et pour générer l'exécutable final?
Voila une conférence qui tombe à pic après la news sur PCC et ses discussions animées!
On va pouvoir voir que GCC ne reste pas inactif face aux critiques.
Je suis très intéressé par le contenu de cette présentation mais je ne pourrais malheureusement pas y assister.
Est ce que vous allez mettre à disposition le(s) support(s) de présentation et / ou une vidéo sur cette conférence?
Justement! D'après ce que je comprends, la compilation native est un des tests pour vérifier que OpenBSD marche correctement sur une architecture cible.
Le seul moment ou OpenBSD utilise la cross compilation, c'est pour initier un nouveau port. Ensuite ils font de la compilation native.
Et bien d'après ce qui se dit dans cette news et les commentaires voici les principaux problèmes:
- GCC n'est pas assez modulaire (séparation nette entre la partie de GCC qui lit le fichier source et crée un arbre du programme, entre la partie intermédiaire qui transforme cet arbre en un autre, entre la partie de GCC qui génère l'assembleur pour l'architecture cible), ce qui le rend difficile a maintenir.
- critique des développeurs d'OpenBSD: GCC abandonne régulièrement des architectures (qu'OpenBSD supporte toujours) et GCC ne marche pas correctement sur les architectures moins courantes (qui ne sont pas x86, x86-64, itanium, power)
- GCC est lent pour compiler, ce qui est gênant pour OpenBSD car ils compilent OpenBSD en continu et en natif sur de vieilles architectures / machines.
- ce n'est pas faire un tort de dire des développeurs d'OpenBSD qu'ils sont des maniaques de la qualité (revues de codes permanentes, durcissement du système en intégrant le plus possible de technologies pour sécuriser le système) et ils disposent d'un compilateur GCC extrêmement modifié pour intégrer des technologies de sécurité, d'où l'intérêt pour eux de disposer d'un compilateur extrêmement simple dont ils peuvent facilement revoir le code (le code de GCC est énorme).
- enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.
Le problème n'est pas dans la nationalité de la boite (MS-France paye aussi des impôts en France, faut pas croire)
Ce n'est pas tout a fait vrai. Certes MS France paie ses charges sociales en France, par contre lorsque MS France vend des logiciels, le contrat est signé avec MS Irlande car les taxes y sont très faibles.
C'est ainsi que la plupart des revenus de MS en Europe s'évadent fiscalement en transitant par l'Irlande. MS (comme beaucoup d'entreprise américaine utilisant ce type de montage financier) ne paye quasiment pas de taxes en France sur la vente de logiciels.
Alors qu'il me semble qu'une entreprise ayant son siège en France va plus difficilement utiliser ce type de montage financier (mais je ne suis ni juriste, ni ne jongle avec les finances d'une entreprise).
1. Quand et comment avez-vous connu DLFP ?
En 2003, a la fin de ma licence informatique.
Je ne me rappelle plus comment je l'avais trouvé, mais je sais que j'y passe beaucoup de temps depuis, et notamment lors du stage qui a suivi.
2. Quel est votre niveau de fréquentation ?
Quasi quotidien
3. Quels sont les contenus que vous lisez ? Ceux que vous ne lisez jamais ?
Je lis les dépêches, parfois les journaux quand ils y a un lien depuis une dépêche.
4. Quelle est votre opinion personnelle sur DLFP ?
C'est un site que l'adore avec ses gens super pointus super compétents capables d'avoir des conversations super technique sur un sujet dont tu ne connais rien, mais c'est aussi le même site avec des trolls velus qui finissent bien loin de la discussion de départ.
5. Quels sont, selon, vous les points forts de DLFP ? Les raisons de son succès ? Ce que vous appréciez le plus ?
il y a l'actualité du logiciel libre, il y a une super communauté pour éclairer, expliquer, présenter tout ça, il y a l'équipe des admodérolecteurs qui fait un super travail, à tel point que je me demande s'il leur reste du temps à la fin de la journée.
6. A contrario, les faiblesses de votre point de vue ?
Ce n'est pas toujours très accessible aux non avertis.
Mais c'est un peu le vieil esprit hacker avec RTFM, Do it yourself, etc.
7. Comment percevez-vous l'influence de DLFP dans le monde du logiciel libre ?
J'en sais rien du tout. Peut être le rassembleur de la communauté francophone du logiciel libre.
8. Votre meilleur souvenir/troll/discussion sur LinuxFr (avec un lien si possible) ?
Je passe.
9. Avez-vous déjà posté/proposé du contenu sur DLFP ?
Une dépêche qui a été refusée parce qu'elle n'avait rien à voir avec le logiciel libre. Et un journal tout pourris.
Je suis plutôt un lecteur / observateur assez silencieux.
10. DLFP, LinuxFr ou GNU/LinuxFr ?
C'est clairement LinuxFr, mais j'aime bien DLFP pour la version abrégée.
Pierre n'a pas parlé de reverse engineering sur OpenXML. Il parlait de reverse engineering sur les documents binaires.
Or il se trouve qu'OpenOffice sait lire ces documents depuis bien avant 2006 et même mieux que MS Office lui-même. Surtout les plus anciens formats.
Et en 2006, Microsoft a décider d'ouvrir les spécifications de ses formats binaires, car ce n'était plus un avantage décisif pour eux:
- OpenOffice avait déja réussi a faire un très bon reverse engineering dessus
- la commission européenne mettait la pression sur Micriosoft pour ouvrir les spécifications de ses protocoles et formats pour faire cesser sa position dominante.
Ensuite, devant la révolution que représentait le stockage de documents Office en XML (et OpenDocument étant ISO), Microsoft s'est décidé a passer a du XML, avec une traduction directe des formats binaires (au lieu de faire un nouveau format cohérent). Cela leur permettait de faire d'une pierre quatre coups:
- ralentir ses concurrents qui doivent implémenter encore un nouveau filtre (sachant que Microsoft l'avait déjà implémenté); alors que Microsoft abandonne le support d'anciens formats MS Office (plus d'autres).
- semer la zizanie parmi les défenseurs du libres entre les pour et les contre
- essayer de satisfaire la commission européenne
- en bien sur, faire une pub énorme en leur faveur en prétendant: "Regardez comme on est favorables aux formats ouverts (sic). On a ouvert le format de notre suite MS Office pour que tous le monde puisse le lire sans problème". Sauf que pour lire effectivement ce format, si tu n'es pas MS Office tu vas devoir reproduire tous les bugs de MS Office et te cogner tous les détails d'implémentation tordus de ce format. Bon courage.
Les inconnus disaient: "Ne pas prendre les gens pour des cons mais ne pas oublier qu'ils le sont."
Dites mois si je me trompe, mais en regardant cette page [1], ainsi que son équivalent anglais, il me semble que contribuer à une paire de langues existante revient a refaire une partie du travail réalisé dans un dictionnaire orthographique (notamment celui qui consiste a éliminer les doublons) en l'enrichissant des correspondances qui existent entre les termes des deux langues.
Si vous ne voyez pas de quoi je parle avec le dictionnaire d'orthographe, vous pouvez regarder cette discussion très intéressante qui explique comment c'est fait [2].
Vous pouvez aussi aller jeter un coup d'oeil sur le projet Dicollecte[1] qui vise à améliorer les dictionnaires orthographiques français pour OpenOffice.org et pour Firefox, Thunderbird et Seamonkey.
Donc je me demandais s'il ne serait pas possible pour ces projets de réutiliser des données?
Par ailleurs, je pense qu'Apertium doit disposer d'une compréhension de la grammaire de chaque langue, il semble naturel de penser qu'il soit possible de travailler de concert avec Language Tool pour construire des données ensemble et essayer de s'améliorer mutuellement?
Une machine virtuelle? Tu ne ferais pas une confusion avec le compilateur JIT? Tu peux avoir un compilateur JIT sans avoir de machine virtuelle. Il y a un exemple dans le tutoriel sur comment utiliser LLVM en tant que compilateur JIT.
Je ne suis pas sur de quel niveau de contrôle tu disposes sur le code source de l'application a surveiller. C'est un binaire ou tu disposes du code source?
Ce que t'as dit Victor STINNER me semble tout a fait valide si tu ne disposes pas du code source.
Cependant si tu en disposes, tu peux regarder du coté de Valgrind qui exécute un bytecode représentant ton programme en contrôlant beaucoup de choses. Peut être que ça peut marcher.
Ensuite je ne sais pas exactement quel est ton but pur contrôler les appels aux bibliothèques externes, mais autrement WINE a du faire beaucoup de travail dans ce domaine pour trouver les fonctions appelées par les binaires Win32 pour pouvoir ensuite les réimplémenter dans leur code source pour Linux / Unix.
Si leur implémentation reste open source, que leur reprocher réellement ?
Je pensais que GTalk était entiérement propriétaire. Je ne savais pas que la libjingle était libre. Au temps pour moi. Si la jabber foundation est un frein je comprends qu'ils veuillent passer outre elle.
Je n'ai pas de reproches a faire sur le fait d'utiliser le libre puisque justement, ... c'est libre.
Je pense effectivement que le passage au binaire pourrait améliorer significativement les performances du protocole. A partir du moment ou cela reste standardisé et ouvert, je ne vois pas de problèmes.
Je t'avoue que ce n'est pas tant le fait que ce soit du binaire qui me dérange, mais plutôt que Gtalk se désolidarise de Jabber/XMPP. Ce changement dans le nom des packages annonce que GTalk ne va plus être compatible avec l'implémentation actuelle de XMPP. C'est un désaveu très fort pour ce protocole que l'on pensait bien parti avec son implémentation dans GTalk.
Maintenant, peut être que c'est l'intention de Google de d'abord pousser les améliorations au protocole dans GTalk puis de les standardiser, mais vu les virages que prend cette entreprise actuellement, le doute m'assaille. Je serais très heureux de me tromper et que GTalk ne rejoigne pas la liste des logiciels d'IM utilisant des protocoles propriétaire: http://fr.wikipedia.org/wiki/Messagerie_instantan%C3%A9e#Pro(...) http://nyco.wordpress.com/2007/01/06/mais-quel-bordel/
> de toutes facons, tu ne peux pas dire a la place de l'auteur du code qui a sorti son soft sous BSD "Non, maintenant tu n'a plus le droit de faire ci ou ca" ; c'est son code !
Oui j'ai bien conscience de ca. Ce que je disais plus haut etait simplement pour le cas suivant:
- le projet A est sous NCSA
- le projet B rajoute du code GPL au code BSD et distribue le tout sous GPL.
- les fichiers copié depuis le projet A dans le projet B doivent rester sous licence NCSA, même dans le SVN du projet B.
Bien évidemment, on est d'accord que les fichiers sous licence NCSA du projet A restent sous licence NCSA tant que le contributeur ne modifie pas cette licence. Mais même dans ce cas, a-t-il le droit de demander au projet B de modifier la licence du code copié? Je crois qu'en France, les droits moraux lui en donneraient le droit, mais quid des US?
>> J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
> Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.
En fait, Je me suis mal exprimé. Quand je disais qu'il n'y en a pas besoin, je ne parlais pas du fichier C en lui même qui n'est qu'un adaptateur pour le blob binaire. Ce que je voulais dire c'est que ce fichier ne me semble même pas avoir besoin d'être sous GPL pour que le processus décrit marche sans enfreindre la GPL.
> Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.
En regardant sur le wiki d'Ubuntu la procédure a suivre pour installer manuellement le driver proprio d'ATI, j'ai des doutes sur ce qu'ils font (a moins qu'apt-get soit capable de compiler du code): https://help.ubuntu.com/community/BinaryDriverHowto/ATI
C'est pas pour les dénoncer, mais plutôt pour comprendre comment ils contournent le problème.
> Il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire.
J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver.
Bref, je comprends maintenant mieux l'opposition de RMS a la modularisation de GCC, même si je ne suis pas d'accord avec elle.
[^] # Re: Le support du HTML 5 s'améliore...
Posté par djano . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 4.
Il ne supporteront pas le h264 car ceux qui reprennent le code de Firefox (distributions Linux, Flock, etc.) ne disposeraient pas eux même de la licence et donc ne pourraient pas reprendre le code tel quel.
De plus, la MoFo soutient les standards ouverts sur Internet, donc pousser h264 serait un manquement a leurs idéaux.
# Sozi
Posté par djano . En réponse à la dépêche Meilleurs contributeurs LinuxFr : Les gagnants de décembre 2009. Évalué à 1.
C'est super sympa comme projet, en plus le principe est très simple!
Pour le problème de performance, ca devrait s'ameliorer pour Firefox 3.6:
http://hacks.mozilla.org/2010/01/javascript-speedups-in-fire(...)
En gros, le problème de saccades pour les animations vient du Garbage Collector. En réduisant la pause due au GC, cela devrait améliorer les performances. Et ceci sans compter les améliorations sur le moteur Javascript lui même, comme l'amélioration de l'accès aux propriétés du DOM que tu dois utiliser dans ton code.
[^] # Re: De la compétition entre nations ?
Posté par djano . En réponse à la dépêche La Jordanie adopte les logiciels libres avec le support de Ingres. Évalué à 2.
Acc%C3%A8s_%C3%A0_la_mer
[^] # Re: Fils ou pere?
Posté par djano . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 3.
Ainsi il n'y a pas de changement de contexte pour le père qui peut s'exécuter tranquillement et le fils peut s'exécuter en parallèle.
Néanmoins le problème que tu soulèves a propos des copies inutiles de pages mémoires me semble toujours être la. Est ce qu'il s'agit vraiment d'un gros problème? Peut être pas, d'où l'intérêt du patch en question.
[^] # Re: Ca permet de vite reprendre ses marques
Posté par djano . En réponse à la dépêche Formation JAVA : + de 100 tutoriaux progressifs pour s'auto-former. Évalué à 1.
Bien sur, en cas de problèmes, et bien ce ne sera pas si facile puisqu'il manquera les bases.
Effectivement, les tutoriels sont perfectibles. D'où l'intérêt que ce soit libre! Il ne leur reste plus qu'a préciser la licence et a l'indiquer sur les pages et a vraiment s'ouvrir en acceptant les contributions de l'extérieur.
[^] # Re: pourquoi ils n'utilisent pas une bibliothèque multi-plateforme ?
Posté par djano . En réponse à la dépêche Prototype du nouveau thème de Firefox 3.7 sous Linux. Évalué à 3.
Apache httpd était historiquement base sur des processus, puis ils sont passés sur un modèle ou ils utilisent des threads.
De plus, il y a des comparatifs sur la gestion mémoire. Plus il y a d'onglets ouverts, plus Google Chrome consomme de mémoire que Firefox, mais alors vraiment beaucoup plus.
Alors il y effectivement des avantages, mais il y a aussi des inconvénients.
[^] # Re: À rebours?
Posté par djano . En réponse à la dépêche GDB 7.0 et le déverminage concurrentiel à rebours. Évalué à 3.
C'était l'approche choisie.
Quand à lui, l'omniscient debugger pour Java enregistre des informations lors de l'exécution du programme. Et lorsque l'on fait un pas en arrière, il consulte juste ce qui avait été enregistré, et utilise juste cette mémoire pour revenir en arrière. Il était possible de paramétrer la quantité de données que le debugger peut utiliser pour se rappeler les états précédents.
Je pense que l'approche 1 convient à un programme bas niveau alors que l'approche 2 convient à un programme plus haut niveau. Le programme bas niveau doit se rappeler plus de choses.
[^] # Re: Pinaise
Posté par djano . En réponse à la dépêche Retour sur le quizz des onze ans du site LinuxFr.org. Évalué à -2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par djano . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 0.
Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile. Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Ce qui n'a rien a voir avec «intensivement testé».
Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
Pour un truc «intensivement testé» et donc «deverminé», c'est un peu opposé a «supporte meme pas les threads».
Je vois pas le rapport.
Trop génial : un lock global.
Ah non, y'a pas a dire, trop top génial gc... completement testé.
Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
Ahem Python a aussi un lock global. Linux, FreeBSD avaient un lock global jusqu'à récemment. Pourtant ils étaient déjà utilisé en production mais pas finalisés selon toi? Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
M'enfin si ça t'amuse continue a critiquer dans le vent.
[^] # Re: The CC Wars
Posté par djano . En réponse à la dépêche LLVM 2.4 : le compilateur qui fait plus. Évalué à 4.
A priori, si ton projet le supporte, tu pourrais utiliser LLVM pour développer (cycle code / compile / éxécution rapide), et utiliser GCC pour générer les binaires pour les équipes de test et pour générer l'exécutable final?
# Ca tombe bien!!
Posté par djano . En réponse à la dépêche Conférence Parinux : Le compilateur GCC vu de l'intérieur, et son évolution. Évalué à 4.
On va pouvoir voir que GCC ne reste pas inactif face aux critiques.
Je suis très intéressé par le contenu de cette présentation mais je ne pourrais malheureusement pas y assister.
Est ce que vous allez mettre à disposition le(s) support(s) de présentation et / ou une vidéo sur cette conférence?
[^] # Re: Besoins d'OpenBSD
Posté par djano . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 2.
Le seul moment ou OpenBSD utilise la cross compilation, c'est pour initier un nouveau port. Ensuite ils font de la compilation native.
[^] # Re: Qu'est-ce qui foire dans GCC ?
Posté par djano . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 10.
- GCC n'est pas assez modulaire (séparation nette entre la partie de GCC qui lit le fichier source et crée un arbre du programme, entre la partie intermédiaire qui transforme cet arbre en un autre, entre la partie de GCC qui génère l'assembleur pour l'architecture cible), ce qui le rend difficile a maintenir.
- critique des développeurs d'OpenBSD: GCC abandonne régulièrement des architectures (qu'OpenBSD supporte toujours) et GCC ne marche pas correctement sur les architectures moins courantes (qui ne sont pas x86, x86-64, itanium, power)
- GCC est lent pour compiler, ce qui est gênant pour OpenBSD car ils compilent OpenBSD en continu et en natif sur de vieilles architectures / machines.
- ce n'est pas faire un tort de dire des développeurs d'OpenBSD qu'ils sont des maniaques de la qualité (revues de codes permanentes, durcissement du système en intégrant le plus possible de technologies pour sécuriser le système) et ils disposent d'un compilateur GCC extrêmement modifié pour intégrer des technologies de sécurité, d'où l'intérêt pour eux de disposer d'un compilateur extrêmement simple dont ils peuvent facilement revoir le code (le code de GCC est énorme).
- enfin d'après OpenBSD, le travail avec les développeurs GCC n'est pas facile car ils n'intègrent pas les patches soumis par OpenBSD ou globalement ont des vues très différentes sur les objectifs d'un compilateur. Pour résumer: OpenBSD voient le compilateur comme une opportunité de renforcer les contrôles du code et est donc un élément essentiel pour sécuriser tout le système,alors que les développeurs GCC sont à la recherche maximale de performance du binaire compilé.
[^] # Re: interêt ?
Posté par djano . En réponse à la dépêche Migration du Parlement européen : soutenez la déclaration pour le Logiciel Libre. Évalué à 5.
Le problème n'est pas dans la nationalité de la boite (MS-France paye aussi des impôts en France, faut pas croire)
Ce n'est pas tout a fait vrai. Certes MS France paie ses charges sociales en France, par contre lorsque MS France vend des logiciels, le contrat est signé avec MS Irlande car les taxes y sont très faibles.
C'est ainsi que la plupart des revenus de MS en Europe s'évadent fiscalement en transitant par l'Irlande. MS (comme beaucoup d'entreprise américaine utilisant ce type de montage financier) ne paye quasiment pas de taxes en France sur la vente de logiciels.
Alors qu'il me semble qu'une entreprise ayant son siège en France va plus difficilement utiliser ce type de montage financier (mais je ne suis ni juriste, ni ne jongle avec les finances d'une entreprise).
# A mon tour!
Posté par djano . En réponse à la dépêche Les dix ans de LinuxFR.org : les festivités. Évalué à 1.
En 2003, a la fin de ma licence informatique.
Je ne me rappelle plus comment je l'avais trouvé, mais je sais que j'y passe beaucoup de temps depuis, et notamment lors du stage qui a suivi.
2. Quel est votre niveau de fréquentation ?
Quasi quotidien
3. Quels sont les contenus que vous lisez ? Ceux que vous ne lisez jamais ?
Je lis les dépêches, parfois les journaux quand ils y a un lien depuis une dépêche.
4. Quelle est votre opinion personnelle sur DLFP ?
C'est un site que l'adore avec ses gens super pointus super compétents capables d'avoir des conversations super technique sur un sujet dont tu ne connais rien, mais c'est aussi le même site avec des trolls velus qui finissent bien loin de la discussion de départ.
5. Quels sont, selon, vous les points forts de DLFP ? Les raisons de son succès ? Ce que vous appréciez le plus ?
il y a l'actualité du logiciel libre, il y a une super communauté pour éclairer, expliquer, présenter tout ça, il y a l'équipe des admodérolecteurs qui fait un super travail, à tel point que je me demande s'il leur reste du temps à la fin de la journée.
6. A contrario, les faiblesses de votre point de vue ?
Ce n'est pas toujours très accessible aux non avertis.
Mais c'est un peu le vieil esprit hacker avec RTFM, Do it yourself, etc.
7. Comment percevez-vous l'influence de DLFP dans le monde du logiciel libre ?
J'en sais rien du tout. Peut être le rassembleur de la communauté francophone du logiciel libre.
8. Votre meilleur souvenir/troll/discussion sur LinuxFr (avec un lien si possible) ?
Je passe.
9. Avez-vous déjà posté/proposé du contenu sur DLFP ?
Une dépêche qui a été refusée parce qu'elle n'avait rien à voir avec le logiciel libre. Et un journal tout pourris.
Je suis plutôt un lecteur / observateur assez silencieux.
10. DLFP, LinuxFr ou GNU/LinuxFr ?
C'est clairement LinuxFr, mais j'aime bien DLFP pour la version abrégée.
[^] # Re: RTP
Posté par djano . En réponse à la dépêche Vorbis sur RTP. Évalué à 2.
Une licence libre (FSF) est nécessairement open source (OSI ou Debian), mais pas l'inverse!!
[^] # Re: La guerre des formats de bureautique normalisés ISO commence
Posté par djano . En réponse à la dépêche La guerre des formats de bureautique normalisés ISO commence. Évalué à 5.
Or il se trouve qu'OpenOffice sait lire ces documents depuis bien avant 2006 et même mieux que MS Office lui-même. Surtout les plus anciens formats.
Et en 2006, Microsoft a décider d'ouvrir les spécifications de ses formats binaires, car ce n'était plus un avantage décisif pour eux:
- OpenOffice avait déja réussi a faire un très bon reverse engineering dessus
- la commission européenne mettait la pression sur Micriosoft pour ouvrir les spécifications de ses protocoles et formats pour faire cesser sa position dominante.
Ensuite, devant la révolution que représentait le stockage de documents Office en XML (et OpenDocument étant ISO), Microsoft s'est décidé a passer a du XML, avec une traduction directe des formats binaires (au lieu de faire un nouveau format cohérent). Cela leur permettait de faire d'une pierre quatre coups:
- ralentir ses concurrents qui doivent implémenter encore un nouveau filtre (sachant que Microsoft l'avait déjà implémenté); alors que Microsoft abandonne le support d'anciens formats MS Office (plus d'autres).
- semer la zizanie parmi les défenseurs du libres entre les pour et les contre
- essayer de satisfaire la commission européenne
- en bien sur, faire une pub énorme en leur faveur en prétendant: "Regardez comme on est favorables aux formats ouverts (sic). On a ouvert le format de notre suite MS Office pour que tous le monde puisse le lire sans problème". Sauf que pour lire effectivement ce format, si tu n'es pas MS Office tu vas devoir reproduire tous les bugs de MS Office et te cogner tous les détails d'implémentation tordus de ce format. Bon courage.
Les inconnus disaient: "Ne pas prendre les gens pour des cons mais ne pas oublier qu'ils le sont."
# Synergies avec d'autres projets libres?
Posté par djano . En réponse à la dépêche Apertium français-espagnol 0.8.0 vient de sortir. Évalué à 3.
Si vous ne voyez pas de quoi je parle avec le dictionnaire d'orthographe, vous pouvez regarder cette discussion très intéressante qui explique comment c'est fait [2].
Vous pouvez aussi aller jeter un coup d'oeil sur le projet Dicollecte[1] qui vise à améliorer les dictionnaires orthographiques français pour OpenOffice.org et pour Firefox, Thunderbird et Seamonkey.
Donc je me demandais s'il ne serait pas possible pour ces projets de réutiliser des données?
Par ailleurs, je pense qu'Apertium doit disposer d'une compréhension de la grammaire de chaque langue, il semble naturel de penser qu'il soit possible de travailler de concert avec Language Tool pour construire des données ensemble et essayer de s'améliorer mutuellement?
[1] http://xixona.dlsi.ua.es/wiki/index.php/Comment_contribuer_%(...)
[2] https://linuxfr.org//comments/903125.html#903125
[3] http://dico.savant.free.fr
[^] # Re: Virtual Machine
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 1.
Je ne suis pas sur de quel niveau de contrôle tu disposes sur le code source de l'application a surveiller. C'est un binaire ou tu disposes du code source?
Ce que t'as dit Victor STINNER me semble tout a fait valide si tu ne disposes pas du code source.
Cependant si tu en disposes, tu peux regarder du coté de Valgrind qui exécute un bytecode représentant ton programme en contrôlant beaucoup de choses. Peut être que ça peut marcher.
Ensuite je ne sais pas exactement quel est ton but pur contrôler les appels aux bibliothèques externes, mais autrement WINE a du faire beaucoup de travail dans ce domaine pour trouver les fonctions appelées par les binaires Win32 pour pouvoir ensuite les réimplémenter dans leur code source pour Linux / Unix.
J'espère que ça t'aide.
[^] # Re: Les mauvaises décisions
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
Je pensais que GTalk était entiérement propriétaire. Je ne savais pas que la libjingle était libre. Au temps pour moi. Si la jabber foundation est un frein je comprends qu'ils veuillent passer outre elle.
Je n'ai pas de reproches a faire sur le fait d'utiliser le libre puisque justement, ... c'est libre.
[^] # Re: Les mauvaises décisions
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
Je t'avoue que ce n'est pas tant le fait que ce soit du binaire qui me dérange, mais plutôt que Gtalk se désolidarise de Jabber/XMPP. Ce changement dans le nom des packages annonce que GTalk ne va plus être compatible avec l'implémentation actuelle de XMPP. C'est un désaveu très fort pour ce protocole que l'on pensait bien parti avec son implémentation dans GTalk.
Maintenant, peut être que c'est l'intention de Google de d'abord pousser les améliorations au protocole dans GTalk puis de les standardiser, mais vu les virages que prend cette entreprise actuellement, le doute m'assaille. Je serais très heureux de me tromper et que GTalk ne rejoigne pas la liste des logiciels d'IM utilisant des protocoles propriétaire:
http://fr.wikipedia.org/wiki/Messagerie_instantan%C3%A9e#Pro(...)
http://nyco.wordpress.com/2007/01/06/mais-quel-bordel/
Finalement est ce que Jabber a vraiment gagné Nÿco?
http://nyco.wordpress.com/2007/07/05/ca-y-est-jabber-a-gagne(...)
[^] # Re: Re:
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
[^] # Re: Re:
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
Oui j'ai bien conscience de ca. Ce que je disais plus haut etait simplement pour le cas suivant:
- le projet A est sous NCSA
- le projet B rajoute du code GPL au code BSD et distribue le tout sous GPL.
- les fichiers copié depuis le projet A dans le projet B doivent rester sous licence NCSA, même dans le SVN du projet B.
Bien évidemment, on est d'accord que les fichiers sous licence NCSA du projet A restent sous licence NCSA tant que le contributeur ne modifie pas cette licence. Mais même dans ce cas, a-t-il le droit de demander au projet B de modifier la licence du code copié? Je crois qu'en France, les droits moraux lui en donneraient le droit, mais quid des US?
[^] # Re: Re:
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
> Si si je t'assure ^^ (il y en a même plusieurs), c'est juste que le fichier .run que tu télécharges sur le site de nvidia est une archive auto-extractible qui exécute ensuite automatiquement la compilation.
En fait, Je me suis mal exprimé. Quand je disais qu'il n'y en a pas besoin, je ne parlais pas du fichier C en lui même qui n'est qu'un adaptateur pour le blob binaire. Ce que je voulais dire c'est que ce fichier ne me semble même pas avoir besoin d'être sous GPL pour que le processus décrit marche sans enfreindre la GPL.
> Je ne connait pas Ubuntu mais je parie que le module n'est pas tout pret à être chargé dans le noyau juste après le téléchargement et qu'au minimum il reste le phase de linkage à faire sur le pc de l'utilisateur.
En regardant sur le wiki d'Ubuntu la procédure a suivre pour installer manuellement le driver proprio d'ATI, j'ai des doutes sur ce qu'ils font (a moins qu'apt-get soit capable de compiler du code): https://help.ubuntu.com/community/BinaryDriverHowto/ATI
C'est pas pour les dénoncer, mais plutôt pour comprendre comment ils contournent le problème.
[^] # Re: Re:
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
> Il distribue d'un coté un fichier C sous GPL, de l'autre un blob binaire.
J'ai téléchargé le fichier et je ne trouve aucune trace du fichier C en GPL. Je pense qu'il n'y en a en fait même pas besoin.
Par contre les distributions qui inclue le driver NVidia avec le noyau linux deviennent alors hors la loi, non?
J'ai regardé pour Ubuntu, et en fait, il semble que le driver est téléchargé a la demande, donc ils sont ok puisque encore une fois c'est l'utilisateur qui installe lui même le driver.
Bref, je comprends maintenant mieux l'opposition de RMS a la modularisation de GCC, même si je ne suis pas d'accord avec elle.