Quatres remarques :
* Les bugs dont parle Monty concernent les nouvelles fonctionnalités (ormis sa brève évocation de 35 bugs graves hérités de 5.0 mais pas corrigés). Il ne s'agit pas de régression (bugs affectant des choses qui marchaient auparavant) ; au contraire : Monty affirme que certains bugs graves de 5.0 sont corrigés dans 5.1, au point qu'il invite à utiliser cette dernière plutôt que la branche 5.0 (mais en mettant en garde contre l'utilisation des nouvelles fonctionnalités).
* PostgreSQL n'est pas exempt de bugs graves. J'en sais quelques choses, j'utilise les deux SGBD dans des environnement à forte sollicitation. Il suffit de consulter le changelog de la 8.3.5 pour voir que la branche 8.3 est sortie avec des problèmes sévères. Je ne dis pas ça pour critiquer ce logiciel (je pense que tout logiciel de cette taille a ce problème), mais pour suggérer de nous épargner les lancers de trolls velus (comme dans le post grand-parent) à chaque fois qu'il est question de MySQL (et oui, même si PG a de nombreux afficionados motivés et passionnés dans les rangs de dflp).
* La décision de ne pas surseoir indéfiniment à la sortie d'une version, malgrè les bugs, est un choix qui peut se défendre, sous certaines conditions. Par exemple Linus Torvalds considère que la qualité du noyau s'effilocherai au fil du temps s'il attendait que tout soit corrigé (il soutient parfois, par exemple, que la release permet de galvaniser les testeurs et d'obtenir plus d'informations sur les bugs torteux, et qu'un délai trop long produirait un déluge ingérable de patchs lors de la « merge window » suivante).
* Un point qui me semble plus gênant, évoqué en fin de dépêche, est la difficulté avec laquelle les employé de Sun intègrent (ou plutôt, ne mergent pas) les patchs externes (ou « de la communauté »). Je pense en particulier aux patchs de Google, Percona, Proven Scalability etc., brefs diverses sociétés employant des anciens devs de MySQL, dont les patchs sont accueillis par des félicitations dans le bug tracker, mais rarement mergés (ou après un très long délai seulement). C'était déjà le cas avant le rachat de MySQL A.B. par Sun, mais vu la politique usuelle de ce dernier (cf. OpenOffice.org ou Java), je crains que les
choses ne s'arrangent pas.
> Par curiosité (et parce que j'ai un peu la flemme de chercher :-p ), quelles sont lesdites limites ?
Je ne sais pas si on peut vraiment parler de « limites ». En pratique, les objectifs et cas d'utilisation de SQLite et de MySQL Embedded sont très différents.
SQLite s'efforce avant tout d'être une bibliothèque petite, compacte et le plus légère possible (en termes de ressources à l'execution comme en termes d'occupation disque). Richard Hipp, le développeur principal de SQLite, répète souvent que l'embarqué (le vrais, sur des machines où même la place sur disque est précieuse au KB près) est la priorité de SQLite, et qu'il est le secteur qui finance la plupart des développements. Par ailleurs SQLite est dans le domaine public, ce qui rend cette bibliothèque adaptée aux applications propriétaires et aux applications libres utilisant autre chose que la GPLv2 (licence de MySQL Embedded).
MySQL Embedded, en revanche, n'est pas réellement un système destiné à l'embarqué au sens strict (quoi que le nom laisse penser), mais plutôt une version « desktop » de MySQL. Les choix sont donc naturellement différents de ceux de SQLite ; ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture. Il offre aussi l'option de ne pas faire de fsync() après commit des données, ce qui permet de laisser à l'OS (au thread pdflush du noyau) l'opportunité d'aggréger les écritures de façon optimale, au risque de perdre 1 ou 2 secondes de données (probablement un bon compromis pour le type d'utilisation d'Amarok ; remarquez que ce fsync() obligatoire a posé de gros problèmes aux développeurs de Firefox lorsque ce dernier a adopté SQLite pour tout stocker).
En bref, MySQL Embedded cible les applications desktop, et Amarok est une application desktop, pour laquelle, en outre, la licence GPLv2 n'est pas un obstacle.
> Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
Certes non, mais les développeurs ont pourtant rapidement du faire face à des problèmes de performances insurmontables avec les grosses collections. D'après leurs dires, les performances sont devenues très correctes après qu'ils aient décidé d'adopter MySQL Embedded comme principal (et en fait, seul) moteur de stockage.
> Il n'y a aucune difference entre les deux, strictement aucune (mise a part des
> pouillemes tellement insignifiant que cela rentre dans les barres d'erreurs probablement).
Tu n'évoque pas un aspect intéressant de ce test : Phoronix ne s'en n'est pas tenu à comparer Fedora et Ubuntu ; ils ont testé et benchmarké 4 choses différentes :
- Ubuntu 8.10 x86
- Ubuntu 8.10 x86_64
- Fedora 10 x86
- Fedora 10 x86_64
S'il n'y a aucune différence de performance significative entre les deux distributions (et pour cause : elles ont la même version du noyau, de gcc, de Xorg, ...), certains tests montrent une différence significative entre le 32 et le 64 bits, toujours à l'avantage du 64 bits :
- Timed Gzip Compression (de 5% à 10% de mieux pour x86_64)
- Lame MP3 Encoding (environ 13%)
- Ogg Encoding (33%)
- Byte (dans les 35%)
- OpenSSL (150 % de mieux !)
Soit en gros presque tout les tests "CPU bound" (les tests impliquant du calcul, plutôt que ceux mesurant / bridés par les perfs de la carte graphique et de son driver dans tel ou tel jeux, et de GnuPG bizarrement).
Dites, ça vous ennuierai de tenter d'essayer de modérer, autant que faire se peux, vos velléités publicitaires pour votre blog ?
Je parcoure à l'instant vos abondantes contributions sur dflp, et il est bien rare d'y trouver autre chose qu'un message introduisant un lien vers votre blog. Au risque de vous surprendre : linuxfr n'est pas seulement une plateforme publicitaire.
D'autant que la richesse de ce dernier trouve malheureusement illustration dans la pertinence de journal...
> Il y a un script shell je ne sais plus où qui fait client FTP, sans commandes externes. Un client mail ça doit pas être beaucoup plus difficile à faire ;)
Bash a une telle fonctionnalité : il intercepte les accès à /dev/tcp (ou /dev/udp) pour en faire des requêtes réseau :
echo -e "GET / HTTP/1.0\r\n\r\n" &> /dev/tcp/127.0.0.1/80
Cette fonctionnalité « intéressante » est heureusement désactivée sur certaines distros.
>>Avec un script tu fais bien plus qu’avec main ou netcat ou autre
>A condition d'avoir le droit d'exécuter les commandes voulues... Et comme /lib/ld-linux.so.2 /tmp/binaire_pas_executable" ne fonctionne pas...
Oui enfin bon, tu a aussi les variantes
sh /tmp/script_non_executable
perl /tmp/script_non_executable
etc.
Les montages en noexec n'apportent _rien_ à la sécurité. C'est du pipeau.
Si vous voulez restreindre l'exécution de fichiers, utilisez SELinux.
C'est comme si tu utilisait le terme « conglomérat d'atomes » pour désigner un être humain. C'est au mieux une métonymie ; être composé d'atomes est une propriété d'un être humain, mais sûrement pas une définition ni même une description adéquate ou pertinente.
Toujours pour filer ta comparaison : sur mon disque dur, on trouve des logs et des oeuvres numérisées, ce sont des informations, mais des choses distinctes. Incidemment, les premiers ne sont pas couverts par le code de la propriété intellectuelle, et ne sont probablement pas l'objet de ton texte. S'agissant de s'affranchir des vieilles notions s'appliquant aux biens matériels, autant ne pas les réintroduire par la fenêtre (avec cette notion d'information implicitement stockable).
Dans notre cas, parler d'information pour dire « oeuvre » renforce la dimension « geek » du propos (et franchement, s'agissant de sensibiliser le grand public à ces questions, on n'a vraiment pas besoin de ça).
Certaines oeuvres, de par leur nature, ne peuvent pas être enregistrées ou conservées sur un ordinateur (certaines performances, des happenings, certaines installations, et tout les cas où l'oeuvre n'existe qu'en présence du spectateur), précisément parce que ce qu'elles sont en tant qu'oeuvre ne se réduit pas à ce qu'elles sont en tant qu'information (ce qu'on pourrait filmer et enregistrer sur un disque dur par ex., ne serait plus l'oeuvre elle-même).
> Mais l'œuvre est de l'information, rien d'autre.
Bah, non.
Lis les exemples ci-dessus.
Quoiqu'il en soit, je pense que tu aurais plutôt intérêt à dégager de ton texte ce qui relève de la philosophie de l'art (comme imposer implicitement et maladroitement une définition de la notion d'oeuvre en l'appelant « information » au lieu d'« oeuvre »), si tu n'es pas introduit à cette discipline, et lorsque ton propos ne nécessite pas une prise de position particulière sur un tel point (qui fait débat entre spécialistes de la discipline, débat qui ne recoupe en rien la question de la culture libre vs. propriétaire). Même remarque au sujet des considération naïves en économie, d'ailleurs.
Le texte gagnerai ainsi en généralité (il s'appliquerait au-delà de partis pris non nécessaires, visiblement involontaires même), en précision (ne pas se disperser), comme en crédibilité (cf. les remarques qui ont été faites plus bas : ton message - et le débat - ont été court-circuités par ces maladresses).
> Le problème n'est pas tant de parler de la vision économique des biens culturels que de les comparer et les réduire à la vision économique des biens matériels
A mon avis tu ne devrais pas te priver d'introduire ces nuances et subtilités dans le paragraphe litigieux.
> je propose en remplacement (Monopole Temporaire sur l'Information)
Je trouve aussi cette expression très mauvaise. Outre les défauts évoqués plus haut (la longueur, par ex.), elle est trop étroite. Le terme « information » ne rends compte (et encore : fort mal) que des bases de données, des oeuvres logicielles ou scientifiques.
L'exclusivité légale des droits patrimoniaux concernant une photographie, un tableau, une chanson, un film, par exemple, ne restreint en rien la diffusion de l'information que véhicule cette oeuvre. Preuve : on peut librement décrire ce dont parle Imagine de John Lennon ; on peut légalement transmettre l'« information » que véhicule un poème.
Le code de propriété intellectuelle limite la jouissance de l'oeuvre (au sens juridique du terme jouissance).
> Si je prends mon dictionnaire d'économie, je vois qu'un bien économique est
> « produit par du travail humain et/ou dont la rareté lui confère une valeur d'échange ».
Pour ce que je comprends des intentions de l'auteur du texte (sinon du texte lui-même), c'est précisément l'ambivalence de cette définition qui encouragerai à chercher un terme moins ambigu.
La culture est effectivement (et entre autres) un bien économique en tant qu'elle est « produite par du travail humain ». Mais nous souhaiterions qu'elle ne le soit pas parce que sa « rareté lui confère une valeur d'échange ».
À l'aire du numérique en particulier, la « rareté » n'est entretenue qu'artificiellement, à grands efforts, par le droit, par l'interdiction légale de modification, de redistribution, etc. là où les conditions matérielles permettent souvent une réutilisation à l'infini sans coûts. DADVSI contre les usagers, brevets, choix de licences des logiciels propriétaires, prolongation des droits patrimoniaux, ... : il s'agit toujours d'établir par la loi une rareté qui n'est pas intrinsèque à l'oeuvre elle-même.
A contrario, la culture libre prouve qu'une économie de la culture peut exister sans s'étayer sur une « rareté artificielle ». Par exemple l'économie du service autour des oeuvres est celle d'un bien monnayable parce que « produit par du travail » et non parce qu'il est rare : support pour les distributions commerciales, développements sur mesure, Jamendo, concerts pour les musiciens, ...
Cette nouvelle alternative ne va pas de soi, est peu intuitive pour beaucoup de gens, et le fait que nos « ennemis » aient choisi les mots, c'est-à-dire le terrain de bataille, y est pour quelque chose.
Enfin l'auteur du texte dénonce l'expression « produits culturels », et tu donne celle de « bien économique ». C'est légèrement différent. Le terme « produit » n'est pas faux, mais il s'enracine dans l'économie des biens matériels, et convoque une charge sémantique qui n'aide pas à présenter une approche différente.
Cela dit je trouve aussi que ce paragraphe n'est pas le plus heureux, j'aurais plutôt écrit que la culture n'est pas en premier lieu un produit de consommation, que ce terme décrit mal ce qu'elle (la culture) a de spécifique, y compris dans le champ de l'économie, encore moins hors de ce champ, etc.
Bravo pour le texte, et tout particulièrement pour le très juste résumé des arguments connus contre l'usage de l'expression « propriété intellectuelle ».
Cette expression a malheureusement réussie à s'imposer hors du cercle des intéressés (membres de l'OMPI, par ex.) et paraît désormais aller de soi pour beaucoup. Il est devenu difficile de faire sentir son inanité à quelqu'un de peu sensibilisé à ces questions (cf. le commentaire plus haut), y compris aux législateurs en France.
Deux textes sur ce point, que je recommande parfois à ces personnes (surtout celui de Doctorow, parce qu'il est particulièrement simple, clair et imagé) :
> C'est une comparaison 32bit x86 vs 64bit amd64 , la plus grande partie
> de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.
Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).
Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.
Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.
En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.
Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).
Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.
Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
- Même stratégie semi-libre que les autres (connecteur Outlook proprio, serveur libre, selon les composants)
- Plus "productifié" que les autres. C'est une paire de daemons en C++(pas de java), les dépendances externes sont minimales et présentes par défaut dans RHEL et Debian, et zarafa fournis des .rpm et .deb ; il suffit de quelques lignes de conf limpide pour que ça roule ; ça s'intègre avec n'importe quel MTA (postfix, sendmail, etc). Bref ce n'est pas un bloatware, pour une fois. C'est "clean and lean"
- Leur webmail est très bien (et libre aussi)
- Ils distribuent une lib MAPI libre pour php, et une lib ActiveSync libre aussi (Z-Push)
- Outlook est une grosse merde, Zarafa ou pas. Les clients sous thunderbird se portent mieux. Si vous voulez migrer vers une solution groupware (que ce soit OBM, Zarafa, Zimbra ou autre) par que les decideurs veulent du "Exchange" parce-que-cé-dans-le-vent, ils voudront aussi des Outlook, et vous aurez des emmerdes.
- Le concept - introduit par MS et plébiscité par les dissailldeurs préssés - de stocker tout le brouzouf de mails sur un serveur et d'avoir 1000 péquins qui y accèdent fébrilement en permanence avec des clients lourds comme si c'était sur leurs disque locaux est quand même bien con à la base.
Il y a eu une série de débats sur la LKML récemment, car des éditeurs d'antivirus souhaitaient implémenter et faire intégrer des API permettant ce type de fonctionnalités dans le noyau Linux.
Un "cas d'utilisation" standard et clair était justement ce qui faisait défaut, lors de la première tentative d'introduction. Ou plutôt, il manquait la description précise de la menace dont c'était censé nous protéger : les exigences ne sont pas les mêmes selon qu'on cherche à protéger contre une attaque fine et ciblée - ie. un daemon root qui exécute du code arbitraire choisi sur mesure par un humain finira par prendre le dessus sur l'antivirus dans le noyau dans tout les cas (ce type de menaces est plutôt couvert par SELinux) - ou contre un code malicieux mais non ciblé, exécuté bêtement par un simple utilisateur imprudent... Il faut bien dire que cette façon de concevoir la protection contre les attaques (une protection facile à contourner mais qui serait suffisante pour s'épargner les bourinages de masse) est plutôt étrangère aux devs Linux.
A la seconde tentative de discussion, les développeurs d'antivirus ont finalement présenté leurs cas d'utilisation nécessitant une plus grande coopération du kernel. Le risque décrit était plutôt l'utilisation de Linux comme un serveur de fichier (samba, nfs, ftp, scp, ...) ou relayant des fichiers (mail, ...). Pour qu'un tel serveur ne soit pas une "zone d'ombre" du SI non protégée, permettant le stockage des virus, et exposant les postes clients, il faudrait intercepter les écritures sur son disque. Utiliser des hooks dans les services (comme ce que permettent Samba ou Postfix) est une solution efficace mais ne couvre pas tout les cas, et il est inenvisageable d'intégrer un hook vers un antivirus dans tout les daemons Linux possibles. Utiliser LD_PRELOAD et surcharger les fonctions open() & co ne couvre pas non plus tout les cas (le serveur nfs tourne dans le noyau, donc pas de lib, le preload ne marche pas pour les daemons liés statiquement, est ignoré par les binaires suid, et il faudrait surcharger les mille et une façons qu'offre linux pour écrire dans un fichier). Inotify ne leur convient pas non plus (notamment parce qu'il ne peux surveiller qu'un nombre limité de fichiers).
Ces débats sont amusants, il y a un coté "choc des cultures". Et c'est intéressant de constater que plusieurs éditeurs d'antivirus tentent de fournir du code noyau libre, et consacrent pas mal d'efforts pour faire merger ce travail (au point qu'ils ont finis par faire appel aux services de Red Hat pour concevoir le design de l'API dont ils avaient besoin, mais le dev. RH sur le coup n'a lui non plus pas encore réussi à proposer de solution qui convainque tout le monde). Beaucoup de pointures participaient aux débats (Alan Cox, Arjan van de Ven, Greg Kroah-Hartman, James Morris, Al Viro, Andi Kleen, Theodore Tso, Nick Piggin, Rieck van Riel, Christoph Hellwig, ...).
> Heu peux tu me citer les différences au niveau du binaire entre celui qui a été cross compiler et celui qui a été compiler nativement par la même version du compilo ?
De fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).
L'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.
C'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».
Confronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).
Une autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...
> Celui avec gcc-3.3.5 (qui au passage n'est pas très récent non plus....) a plus de 10 % d'écart.
Cette remarque au sujet la version de gcc ne manque pas d'ironie. Il est plus que probable que ragge utilise cette version parce que c'est celle qui est incluse dans OpenBSD pour les architectures i386 et amd64. C'est une vieille version parce qu'ils (les devs. d'OpenBSD) n'arrivent pas à suivre le rythme et à maintenir eux-même les versions plus récentes de gcc (les devs. de gcc ne maintiennent pas le port OpenBSD pour eux). Ce qui explique qu'ils cherchent une porte de secours...
Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement, où quelques "low hanging fruits" sont encore à portée de main.
> C'est vrai que le marché mondial pour de l'OpenBSD sur du VAX ou du m68k est tellement gigantesque [...]
Mais bon sang, on parle d'un OS d'amateurs, de gens qui développent pour le plaisir, alors oui, Vax est capital, et ils y consacrent du temps. Tu semble ne pas le croire, mais ça l'est vraiment, pour eux, au moins.
En tout cas parler de "marché", fut-ce au figuré, montre où se niche la confusion. C'est précisément là où se trouve le sel des BSD (et certainement où devait être le fun dans le petit monde de Linux avant 1998 environ) : une petite famille, peu de développeurs, tous sont connus, peu de patchs (on peut suivre les changements), bref des projets à taille humaine ; un engouement pour les vieilles machines, du code pour le plaisir du code (ou pour sa beauté, sa simplicité avant son efficacité, par ex.) comme de l'art pour l'art, ou plutôt de l'artisanat, et vraiment rien de corporate. Pas de "marché". GCC pour sa part est touché par l'excès inverse.
D'ailleurs, cette propriété en soi ça suffit à expliquer ce travail sur PCC (bien que ça ne soit pas la seule raison) : même s'il est probable que ça fasse un compilateur plus lent et moins complet, il y a un certain nombre de développeurs qui ont envie de mettre les mains dans les entrailles d'un compilateur au code clean et à dimension humaine. Juste pour le plaisir du bricolage, de l'amateurisme éclairé.
> Y'a quand même un bel avantage technique qui est sorti de la position de Stallman :
> Apple a contribué au support d'Objective-C dans GCC alors que si il était possible
> d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain")
> que le support d'Objective-C serait resté purement dans le giron d'Apple.
C'est marrant que prenne cet exemple, parce que Apple, qui est le principal contributeur de LLVM (qu'ils "donnent" gratuitement donc), a montré qu'on peux faire un compilateur modulaire, sous licence BSD, et auquel des boites peuvent contribuer sans radinerie mesquine. LLVM est le parfait contre-exemple de la théorie politique de GCC.
> Pourquoi ne pas opter pour la solution évidente : quand on écrit le programme et qu'on fait pleins de cycles compilation/modifs/compilation alors n'optimise pas du tout le code pour que la compilation soit rapide (-O0)
Parce que c'est bien trop lent de toutes façons (la différence avec ou sans optims est minimale).
Le projet OpenBSD se fait fort de compiler ses binaires pour toutes les architectures supportées (y compris de _très vieilles archis_) sur la plateforme elle-même. Ce qui évite par ex. de faire comme les devs NetBSD, qui s'aperçoivent parfois des mois après qu'une archi est cassé parce que ça passait bien à la cross-compilation... Et ça permet de stress tester le noyau en cours de développement sur ces architectures : c'est de l'intégration continue, en somme. Évidemment ça marche moins bien quand on a un compilo lent et mal supporté (mal supporté : sur l'archi/plateforme en question, comme tu semble ne pas comprendre...).
>Si Theo pense vraiment que GCC n'est pas maintenu upstream alors il doit vivre dans un monde parallèle au notre
[...]
> Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Il apparait que TdR en sait un poil plus long que toi sur les compilos et la façon dont ils sont maintenus. Un boût de phrase, évident mais implicite t'aurait sans doute aidé à comprendre ce dont parle Théo : il n'est pas assez maintenu ... pour les choses qui importent à OpenBSD.
En l'occurrence, OpenBSD se traine sur certaines plateformes un vieux gcc 2.95 (et les autres sont restées en 3.3, d'ailleurs) parce que support par le gcc "upstream" a été délaissé. Le support pour la plateforme OpenBSD est lui aussi, bien entendu, à la charge des devs OpenBSD : les grosses boites qui paient des développeurs à plein temps pour améliorer gcc n'ont que fiche des OpenBSD sur Vax et archis pour bricoleur dinosaures. Le m68k n'est sans doute plus assez corporate. Ces grosses boites font évoluer le logiciel, très vite (ce qui est d'autant plus dur à suivre, du coup), précisément, et l'écart à rattraper pour maintenir les fonctionnalités _qui importent à OpenBSD_ se creuse chaque jour.
Ce mode de fonctionnement est tout à fait justifié de la part de gcc, mais il explique aussi le malaise de certains développeurs qui doivent de facto assurer pendant leurs loisir le maintient d'un code qui change très vite, qui change d'une façon qui ne respecte en rien leurs besoins, un code vieux de 23 ans de patchs accumulés, un code qui est volontairement structuré pour ne pas être modulaire.
Très bon résumé des enjeux d'un tel changement de licence pour les œuvres Wikimedia.
Deux note en complément :
* La notion d'invariants dans la GFDL est très controversée, et conduit par exemple Debian à considérer cette licence comme non libre, ce qui est dommage.
* La GFDL contient un grave "bug" juridique, bien exposé par Bruce Perens ici : http://lwn.net/Articles/305757/ (Johnatan Corbet fait remarquer à ce sujet qu'un simple "chmod -r lefichier" pourrait être illégal sur un un fichier en GFDL, de ce fait).
La cause de ces deux problème est une volonté de bien faire, très louable, mais qui se heurte à la pratique.
Pour donner un exemple concret de quelque chose bien expliqué par baud123 ci-dessus, si je veux ré-utiliser une image en GFDL de commons.wikimedia.org pour faire une carte postale, ou pour imprimer sur un t-shirt, je doit imprimer aussi sur ma carte postale (ou mon t-shirt) le long texte de la licence in extenso, alors qu'une url pourrait avoir la même fonction. Pour cette même raison, l'utilisation de cette licence pour des fichiers audio est encore plus inadaptée. C'est, tout simplement, une licence pour la documentation de logiciels.
> ma confiance en la FSF sur les versions futures diminuant
[...]
> Si c'était aussi "équivalent", pourquoi limiter :
> - aux "Massive Multiauthor Collaboration Site" et
> - à des dates précises.
La situation de Wikipédia est assez délicate, et spéciale :
* La licence a été choisie par une toute petite poignée de gens (qui, en plus, reconnaissent eux-même avoir mal choisi) et le projet est devenus le projet libre ayant le plus de contributeurs au monde. On ne connais pas encore le choix de licence qui représenterai au mieux le choix des wikipédiens aujourd'hui.
* A été choisie à une époque où il n'y avait pas vraiment d'alternatives, en terme de licences non logicielles.
* A été choisie à une époque où le projet, ses contraintes, ses besoins, etc. étaient encore mal définis. On s'aperçoit maintenant que cette licence correspond à l'esprit du libre souhaité, mais impose certaines contraintes pratiques très peu adaptées, par ex.
* Divers "bugs" juridiques dans la licence sont apparus depuis lors.
* C'est une licence explicitement conçue et adaptée pour la documentation de logiciels, et wikimedia est certainement le plus gros utilisateurs de cette licence tout en ne produisant rien qui ressemble à une documentation de logiciel.
Les nouvelles clauses restreignant qui a ou n'a pas ce droit de re-licencer un contenu GFDL en CC-BY-SA permettent précisément d'empêcher tout autre que la communauté Wikipédia de faire ce choix à leur place. On ne peux pas en profiter pour télécharger un dump actuel de WP dans son coin et le déclarer "CC-By-SA" tout seul.
Aussi la décision de Stallman est tout à fait honorable, à mon sens, et opposée à ta conclusion : il ne s'agit pas de décider à la place des "copyright owners", mais tout au contraire de leur laisser une fenêtre de choix, un laps de temps où ils pourront prendre une décision collective en conscience. Et c'est précisément ce qui est en train de se mettre en place : un large "référendum" entre Wikipédiens est en préparation.
Notez aussi que la FSF est en train de préparer la GFDL 2.0, qui sera conçue et adaptée, car c'est le but de cette licence, pour les manuels de logiciels libres et non les encyclopédies libres. Et on comprends bien que la FSF ne veuille pas se trainer des contraintes hors du champs initial de cette licence simplement parce qu'une poignée de pionniers de wp ont fait un choix un peu trop "léger" (ce qu'ils reconnaissent eux mêmes).
Enfin, le "contrat moral" implicite entre les utilisateurs d'une licence qui choisissent "ou version ultérieur" et la FSF est celui-ci : l'utilisateur est en droit d'attendre que la FSF fera évoluer la licence _en conservant son esprit_. Or à mon sens, si la FSF s'était bornée à copier-coller le texte de la CC-BY-SA in extenso et d'appeler ça "GFDL 1.3", l'esprit de la licence aurait été pleinement conservé. Le changement serait moins radical que, par exemple, le passage de GPLv2 à GPLv3. La FSF a pourtant choisi une mesure encore plus prudente : une astuce permettant à la communauté des "copyright owners" de wikimedia de prendre _leur_ décision à ce sujet. Que pourrais-t-on reprocher à la FSF ?
Il me semble qu'il y a bien moins d'utilisateurs d'OpenBSD que de Linux sur dflp, mais sachez que certaines améliorations seront aussi bénéfiques aux autres systèmes d'exploitations unix-like, Linux compris.
Par exemple, concernant OpenSSH :
- Le sous-système sftp permet désormais de chroot(2)er de force des utilisateurs matchant des règles pré-définies.
- La syntaxe de configuration s'est assouplie : on peux désormais spécifier les adresses au format CIDR dans '.ssh/authorized_keys from="..."', ainsi que les les syntaxe avec négation de d'adresses ou de blocks, comme "Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*" ...
- Très geeky, il y a maintenant une option pour afficher les clefs pub des machines auxquelles on se connecte sous forme d'ASCII art (c'est censé favoriser la reconnaissance des clefs en exploitant la mémoire visuelle, et aider détecter les problèmes)
- Le sous-système sftp s'est vu complété d'émulation des opérations type statvfs(3), et est agrémenté d'une commande "df". Ce qui ne manquera pas d'améliorer les accès sftp depuis les clients émulant un VFS sur SSH (comme gnome-vfs, ou le module FUSE sshfs).
[^] # Re: haha
Posté par herodiade . En réponse à la dépêche La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 6.
* Les bugs dont parle Monty concernent les nouvelles fonctionnalités (ormis sa brève évocation de 35 bugs graves hérités de 5.0 mais pas corrigés). Il ne s'agit pas de régression (bugs affectant des choses qui marchaient auparavant) ; au contraire : Monty affirme que certains bugs graves de 5.0 sont corrigés dans 5.1, au point qu'il invite à utiliser cette dernière plutôt que la branche 5.0 (mais en mettant en garde contre l'utilisation des nouvelles fonctionnalités).
* PostgreSQL n'est pas exempt de bugs graves. J'en sais quelques choses, j'utilise les deux SGBD dans des environnement à forte sollicitation. Il suffit de consulter le changelog de la 8.3.5 pour voir que la branche 8.3 est sortie avec des problèmes sévères. Je ne dis pas ça pour critiquer ce logiciel (je pense que tout logiciel de cette taille a ce problème), mais pour suggérer de nous épargner les lancers de trolls velus (comme dans le post grand-parent) à chaque fois qu'il est question de MySQL (et oui, même si PG a de nombreux afficionados motivés et passionnés dans les rangs de dflp).
* La décision de ne pas surseoir indéfiniment à la sortie d'une version, malgrè les bugs, est un choix qui peut se défendre, sous certaines conditions. Par exemple Linus Torvalds considère que la qualité du noyau s'effilocherai au fil du temps s'il attendait que tout soit corrigé (il soutient parfois, par exemple, que la release permet de galvaniser les testeurs et d'obtenir plus d'informations sur les bugs torteux, et qu'un délai trop long produirait un déluge ingérable de patchs lors de la « merge window » suivante).
* Un point qui me semble plus gênant, évoqué en fin de dépêche, est la difficulté avec laquelle les employé de Sun intègrent (ou plutôt, ne mergent pas) les patchs externes (ou « de la communauté »). Je pense en particulier aux patchs de Google, Percona, Proven Scalability etc., brefs diverses sociétés employant des anciens devs de MySQL, dont les patchs sont accueillis par des félicitations dans le bug tracker, mais rarement mergés (ou après un très long délai seulement). C'était déjà le cas avant le rachat de MySQL A.B. par Sun, mais vu la politique usuelle de ce dernier (cf. OpenOffice.org ou Java), je crains que les
choses ne s'arrangent pas.
[^] # Re: Obligatoire
Posté par herodiade . En réponse au journal La version 5.1 de MySQL est-elle bourrée de bugs ?. Évalué à 10.
Je ne sais pas si on peut vraiment parler de « limites ». En pratique, les objectifs et cas d'utilisation de SQLite et de MySQL Embedded sont très différents.
SQLite s'efforce avant tout d'être une bibliothèque petite, compacte et le plus légère possible (en termes de ressources à l'execution comme en termes d'occupation disque). Richard Hipp, le développeur principal de SQLite, répète souvent que l'embarqué (le vrais, sur des machines où même la place sur disque est précieuse au KB près) est la priorité de SQLite, et qu'il est le secteur qui finance la plupart des développements. Par ailleurs SQLite est dans le domaine public, ce qui rend cette bibliothèque adaptée aux applications propriétaires et aux applications libres utilisant autre chose que la GPLv2 (licence de MySQL Embedded).
MySQL Embedded, en revanche, n'est pas réellement un système destiné à l'embarqué au sens strict (quoi que le nom laisse penser), mais plutôt une version « desktop » de MySQL. Les choix sont donc naturellement différents de ceux de SQLite ; ME peut utiliser, par exemple, un cache en RAM, ce qui a un effet très positif sur les performances pour les requêtes en lecture. Il offre aussi l'option de ne pas faire de fsync() après commit des données, ce qui permet de laisser à l'OS (au thread pdflush du noyau) l'opportunité d'aggréger les écritures de façon optimale, au risque de perdre 1 ou 2 secondes de données (probablement un bon compromis pour le type d'utilisation d'Amarok ; remarquez que ce fsync() obligatoire a posé de gros problèmes aux développeurs de Firefox lorsque ce dernier a adopté SQLite pour tout stocker).
En bref, MySQL Embedded cible les applications desktop, et Amarok est une application desktop, pour laquelle, en outre, la licence GPLv2 n'est pas un obstacle.
> Amarok n'est quand même pas une application ayant des besoins pharamineux en stockage de données...
Certes non, mais les développeurs ont pourtant rapidement du faire face à des problèmes de performances insurmontables avec les grosses collections. D'après leurs dires, les performances sont devenues très correctes après qu'ils aient décidé d'adopter MySQL Embedded comme principal (et en fait, seul) moteur de stockage.
# ... mais il y de belles différences entre x86 et x86_64 !!
Posté par herodiade . En réponse au journal comparaison des performances ubuntu et fedora. Évalué à 8.
> pouillemes tellement insignifiant que cela rentre dans les barres d'erreurs probablement).
Tu n'évoque pas un aspect intéressant de ce test : Phoronix ne s'en n'est pas tenu à comparer Fedora et Ubuntu ; ils ont testé et benchmarké 4 choses différentes :
- Ubuntu 8.10 x86
- Ubuntu 8.10 x86_64
- Fedora 10 x86
- Fedora 10 x86_64
S'il n'y a aucune différence de performance significative entre les deux distributions (et pour cause : elles ont la même version du noyau, de gcc, de Xorg, ...), certains tests montrent une différence significative entre le 32 et le 64 bits, toujours à l'avantage du 64 bits :
- Timed Gzip Compression (de 5% à 10% de mieux pour x86_64)
- Lame MP3 Encoding (environ 13%)
- Ogg Encoding (33%)
- Byte (dans les 35%)
- OpenSSL (150 % de mieux !)
Soit en gros presque tout les tests "CPU bound" (les tests impliquant du calcul, plutôt que ceux mesurant / bridés par les perfs de la carte graphique et de son driver dans tel ou tel jeux, et de GnuPG bizarrement).
Ce qui est une information intéressante pour les lecteurs de ce site, cf. cette récente discussion par exemple : https://linuxfr.org//~JoeltheLion/27503.html
# framablog... encore ?!
Posté par herodiade . En réponse au journal Le troll du vendredi est sur le Framablog. Évalué à 8.
Je parcoure à l'instant vos abondantes contributions sur dflp, et il est bien rare d'y trouver autre chose qu'un message introduisant un lien vers votre blog. Au risque de vous surprendre : linuxfr n'est pas seulement une plateforme publicitaire.
D'autant que la richesse de ce dernier trouve malheureusement illustration dans la pertinence de journal...
Vous vouliez un troll ? ;)
[^] # Re: Pas le même contexte
Posté par herodiade . En réponse au journal Maintenant sous MacOS, bientôt sous Linux. Évalué à 3.
Bash a une telle fonctionnalité : il intercepte les accès à /dev/tcp (ou /dev/udp) pour en faire des requêtes réseau :
echo -e "GET / HTTP/1.0\r\n\r\n" &> /dev/tcp/127.0.0.1/80
Cette fonctionnalité « intéressante » est heureusement désactivée sur certaines distros.
[^] # Re: Pas le même contexte
Posté par herodiade . En réponse au journal Maintenant sous MacOS, bientôt sous Linux. Évalué à 5.
>A condition d'avoir le droit d'exécuter les commandes voulues... Et comme /lib/ld-linux.so.2 /tmp/binaire_pas_executable" ne fonctionne pas...
Oui enfin bon, tu a aussi les variantes
sh /tmp/script_non_executable
perl /tmp/script_non_executable
etc.
Les montages en noexec n'apportent _rien_ à la sécurité. C'est du pipeau.
Si vous voulez restreindre l'exécution de fichiers, utilisez SELinux.
[^] # Re: Mes remarques
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 6.
Toujours pour filer ta comparaison : sur mon disque dur, on trouve des logs et des oeuvres numérisées, ce sont des informations, mais des choses distinctes. Incidemment, les premiers ne sont pas couverts par le code de la propriété intellectuelle, et ne sont probablement pas l'objet de ton texte. S'agissant de s'affranchir des vieilles notions s'appliquant aux biens matériels, autant ne pas les réintroduire par la fenêtre (avec cette notion d'information implicitement stockable).
Dans notre cas, parler d'information pour dire « oeuvre » renforce la dimension « geek » du propos (et franchement, s'agissant de sensibiliser le grand public à ces questions, on n'a vraiment pas besoin de ça).
Certaines oeuvres, de par leur nature, ne peuvent pas être enregistrées ou conservées sur un ordinateur (certaines performances, des happenings, certaines installations, et tout les cas où l'oeuvre n'existe qu'en présence du spectateur), précisément parce que ce qu'elles sont en tant qu'oeuvre ne se réduit pas à ce qu'elles sont en tant qu'information (ce qu'on pourrait filmer et enregistrer sur un disque dur par ex., ne serait plus l'oeuvre elle-même).
[^] # Re: Mes remarques
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 2.
Bah, non.
Lis les exemples ci-dessus.
Quoiqu'il en soit, je pense que tu aurais plutôt intérêt à dégager de ton texte ce qui relève de la philosophie de l'art (comme imposer implicitement et maladroitement une définition de la notion d'oeuvre en l'appelant « information » au lieu d'« oeuvre »), si tu n'es pas introduit à cette discipline, et lorsque ton propos ne nécessite pas une prise de position particulière sur un tel point (qui fait débat entre spécialistes de la discipline, débat qui ne recoupe en rien la question de la culture libre vs. propriétaire). Même remarque au sujet des considération naïves en économie, d'ailleurs.
Le texte gagnerai ainsi en généralité (il s'appliquerait au-delà de partis pris non nécessaires, visiblement involontaires même), en précision (ne pas se disperser), comme en crédibilité (cf. les remarques qui ont été faites plus bas : ton message - et le débat - ont été court-circuités par ces maladresses).
[^] # Re: Branlette intellectuelle.
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 1.
A mon avis tu ne devrais pas te priver d'introduire ces nuances et subtilités dans le paragraphe litigieux.
[^] # Re: Mes remarques
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 4.
Je trouve aussi cette expression très mauvaise. Outre les défauts évoqués plus haut (la longueur, par ex.), elle est trop étroite. Le terme « information » ne rends compte (et encore : fort mal) que des bases de données, des oeuvres logicielles ou scientifiques.
L'exclusivité légale des droits patrimoniaux concernant une photographie, un tableau, une chanson, un film, par exemple, ne restreint en rien la diffusion de l'information que véhicule cette oeuvre. Preuve : on peut librement décrire ce dont parle Imagine de John Lennon ; on peut légalement transmettre l'« information » que véhicule un poème.
Le code de propriété intellectuelle limite la jouissance de l'oeuvre (au sens juridique du terme jouissance).
[^] # Re: Branlette intellectuelle.
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 4.
> « produit par du travail humain et/ou dont la rareté lui confère une valeur d'échange ».
Pour ce que je comprends des intentions de l'auteur du texte (sinon du texte lui-même), c'est précisément l'ambivalence de cette définition qui encouragerai à chercher un terme moins ambigu.
La culture est effectivement (et entre autres) un bien économique en tant qu'elle est « produite par du travail humain ». Mais nous souhaiterions qu'elle ne le soit pas parce que sa « rareté lui confère une valeur d'échange ».
À l'aire du numérique en particulier, la « rareté » n'est entretenue qu'artificiellement, à grands efforts, par le droit, par l'interdiction légale de modification, de redistribution, etc. là où les conditions matérielles permettent souvent une réutilisation à l'infini sans coûts. DADVSI contre les usagers, brevets, choix de licences des logiciels propriétaires, prolongation des droits patrimoniaux, ... : il s'agit toujours d'établir par la loi une rareté qui n'est pas intrinsèque à l'oeuvre elle-même.
A contrario, la culture libre prouve qu'une économie de la culture peut exister sans s'étayer sur une « rareté artificielle ». Par exemple l'économie du service autour des oeuvres est celle d'un bien monnayable parce que « produit par du travail » et non parce qu'il est rare : support pour les distributions commerciales, développements sur mesure, Jamendo, concerts pour les musiciens, ...
Cette nouvelle alternative ne va pas de soi, est peu intuitive pour beaucoup de gens, et le fait que nos « ennemis » aient choisi les mots, c'est-à-dire le terrain de bataille, y est pour quelque chose.
Enfin l'auteur du texte dénonce l'expression « produits culturels », et tu donne celle de « bien économique ». C'est légèrement différent. Le terme « produit » n'est pas faux, mais il s'enracine dans l'économie des biens matériels, et convoque une charge sémantique qui n'aide pas à présenter une approche différente.
Cela dit je trouve aussi que ce paragraphe n'est pas le plus heureux, j'aurais plutôt écrit que la culture n'est pas en premier lieu un produit de consommation, que ce terme décrit mal ce qu'elle (la culture) a de spécifique, y compris dans le champ de l'économie, encore moins hors de ce champ, etc.
# « propriété intellectuelle »
Posté par herodiade . En réponse au journal Termes de propagande à ne pas utiliser malgré soi. Évalué à 3.
Cette expression a malheureusement réussie à s'imposer hors du cercle des intéressés (membres de l'OMPI, par ex.) et paraît désormais aller de soi pour beaucoup. Il est devenu difficile de faire sentir son inanité à quelqu'un de peu sensibilisé à ces questions (cf. le commentaire plus haut), y compris aux législateurs en France.
Deux textes sur ce point, que je recommande parfois à ces personnes (surtout celui de Doctorow, parce qu'il est particulièrement simple, clair et imagé) :
* Cory Doctorow, « Propriété intellectuelle » est un euphémisme malencontreux, http://www.ecrans.fr/Propriete-intellectuelle-est-un,3502.ht(...)
* Richard M. Stallman, Vous avez dit «Propriété intellectuelle» ? Un séduisant mirage, http://www.gnu.org/philosophy/not-ipr.fr.xhtml
[^] # Re: la vraion raison
Posté par herodiade . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 4.
> de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.
Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).
Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.
Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.
En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.
Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).
Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.
Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
[^] # Zarafa
Posté par herodiade . En réponse à la dépêche Groupware OBM et Webmail MiniG, paquets Debian. Évalué à 5.
Si vous voulez un retour de sysadmin :
- Même stratégie semi-libre que les autres (connecteur Outlook proprio, serveur libre, selon les composants)
- Plus "productifié" que les autres. C'est une paire de daemons en C++(pas de java), les dépendances externes sont minimales et présentes par défaut dans RHEL et Debian, et zarafa fournis des .rpm et .deb ; il suffit de quelques lignes de conf limpide pour que ça roule ; ça s'intègre avec n'importe quel MTA (postfix, sendmail, etc). Bref ce n'est pas un bloatware, pour une fois. C'est "clean and lean"
- Leur webmail est très bien (et libre aussi)
- Ils distribuent une lib MAPI libre pour php, et une lib ActiveSync libre aussi (Z-Push)
- Outlook est une grosse merde, Zarafa ou pas. Les clients sous thunderbird se portent mieux. Si vous voulez migrer vers une solution groupware (que ce soit OBM, Zarafa, Zimbra ou autre) par que les decideurs veulent du "Exchange" parce-que-cé-dans-le-vent, ils voudront aussi des Outlook, et vous aurez des emmerdes.
- Le concept - introduit par MS et plébiscité par les dissailldeurs préssés - de stocker tout le brouzouf de mails sur un serveur et d'avoir 1000 péquins qui y accèdent fébrilement en permanence avec des clients lourds comme si c'était sur leurs disque locaux est quand même bien con à la base.
[^] # Re: Et la quarantaine et le système restore
Posté par herodiade . En réponse au journal Rions un peu avec les antivirus. Évalué à 4.
Un "cas d'utilisation" standard et clair était justement ce qui faisait défaut, lors de la première tentative d'introduction. Ou plutôt, il manquait la description précise de la menace dont c'était censé nous protéger : les exigences ne sont pas les mêmes selon qu'on cherche à protéger contre une attaque fine et ciblée - ie. un daemon root qui exécute du code arbitraire choisi sur mesure par un humain finira par prendre le dessus sur l'antivirus dans le noyau dans tout les cas (ce type de menaces est plutôt couvert par SELinux) - ou contre un code malicieux mais non ciblé, exécuté bêtement par un simple utilisateur imprudent... Il faut bien dire que cette façon de concevoir la protection contre les attaques (une protection facile à contourner mais qui serait suffisante pour s'épargner les bourinages de masse) est plutôt étrangère aux devs Linux.
A la seconde tentative de discussion, les développeurs d'antivirus ont finalement présenté leurs cas d'utilisation nécessitant une plus grande coopération du kernel. Le risque décrit était plutôt l'utilisation de Linux comme un serveur de fichier (samba, nfs, ftp, scp, ...) ou relayant des fichiers (mail, ...). Pour qu'un tel serveur ne soit pas une "zone d'ombre" du SI non protégée, permettant le stockage des virus, et exposant les postes clients, il faudrait intercepter les écritures sur son disque. Utiliser des hooks dans les services (comme ce que permettent Samba ou Postfix) est une solution efficace mais ne couvre pas tout les cas, et il est inenvisageable d'intégrer un hook vers un antivirus dans tout les daemons Linux possibles. Utiliser LD_PRELOAD et surcharger les fonctions open() & co ne couvre pas non plus tout les cas (le serveur nfs tourne dans le noyau, donc pas de lib, le preload ne marche pas pour les daemons liés statiquement, est ignoré par les binaires suid, et il faudrait surcharger les mille et une façons qu'offre linux pour écrire dans un fichier). Inotify ne leur convient pas non plus (notamment parce qu'il ne peux surveiller qu'un nombre limité de fichiers).
Ces débats sont amusants, il y a un coté "choc des cultures". Et c'est intéressant de constater que plusieurs éditeurs d'antivirus tentent de fournir du code noyau libre, et consacrent pas mal d'efforts pour faire merger ce travail (au point qu'ils ont finis par faire appel aux services de Red Hat pour concevoir le design de l'API dont ils avaient besoin, mais le dev. RH sur le coup n'a lui non plus pas encore réussi à proposer de solution qui convainque tout le monde). Beaucoup de pointures participaient aux débats (Alan Cox, Arjan van de Ven, Greg Kroah-Hartman, James Morris, Al Viro, Andi Kleen, Theodore Tso, Nick Piggin, Rieck van Riel, Christoph Hellwig, ...).
http://lwn.net/Articles/260918/
http://lwn.net/Articles/292872/
http://kerneltrap.org/mailarchive/linux-kernel/2008/8/18/297(...)
[^] # Re: Besoins d'OpenBSD
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 9.
De fait, les binaires produits devraient être identiques dans les deux cas (compilation native ou croisée).
L'intérêt de la compilation native d'un OS est de permettre de tester, tout en compilant, un bon nombre de composants binaires délicats produits lors de la compilation précédente : la libc, le noyau (vm, système de fichier, ...), les binutils, l'éditeur de lien, le compilateur, make, le shell, ld.so, etc., C'est un échantillon représentatif de logiciels critiques, et cela permet de découvrir bon nombre de problèmes (par ex. les cas où la précédente compilation a produit de mauvais binaires) suffisamment tôt pour corriger et ne pas distribuer ces binaires. Au final, ça permet comme le dit le commentaire parent de « fournir des binaires de qualité », mais pas spécialement de « produire des binaires de qualité » bien sûr.
C'est aussi la démarche de Debian (qui, de ce fait, et pour ne pas masquer un problème qui pourrait se produire sur l'architecture cible, proscrit - ou proscrivait ? est-ce que ça a changé ? - même la production des deb finaux dans des machines virtuelles). Debian est dans une position similaire à OpenBSD dans la mesure ou ce projet rassemble une belle proportion d'amateurs qui travaillent pour le plaisir - ou du moins, qui ne sont pas asservis aux seuls besoins de rentabilité et d'attentes sur un marché - ce qui explique dans les deux cas qu'ils puissent investir des efforts conséquents pour supporter des architectures « non rentables ».
Confronté aux mêmes problèmes (lenteur de gcc sur les vielles machines, compilateur maintenu par des grosses boite intéressées seulement par les principales archis en vente aujourd'hui (x86, x86_64, ppc, itanium, arm, s390) et qui évolue rapidement sans trop se préoccuper des architectures exotiques, etc.), le projet Debian a lui aussi du prendre des décisions douloureuses. En l'occurrence, il a été décidé d'abandonner le support officiel pour les architectures qui ne parviennent pas à suivre la cadence de compilation (entre autres critères).
Une autre limitation de la cross-compilation est que tout logiciel n'est pas « naturellement » cross-compilable. Certains logiciels exécutent au cours de la compilation des binaires produits dans une phase précédente. C'est par exemple cas de python : un interpréteur minimal est initialement produit, qui sert à piloter le reste de la compilation et doit, de ce fait, être exécuté sur la plateforme qui compile. D'autres logiciels utilisent des systèmes de compilation (autres que autotools ou CMake) n'offrant pas de facilités pour la cross-compilation. Les solutions à ces problèmes relèvent généralement du bricolage fragile : patcher lourdement le logiciel à compiler, ou intercepter l'exécution des binaires étrangers pour les rediriger dans un émulateur en espace utilisateur, ...
[^] # Re: Alternative ?
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 5.
Cette remarque au sujet la version de gcc ne manque pas d'ironie. Il est plus que probable que ragge utilise cette version parce que c'est celle qui est incluse dans OpenBSD pour les architectures i386 et amd64. C'est une vieille version parce qu'ils (les devs. d'OpenBSD) n'arrivent pas à suivre le rythme et à maintenir eux-même les versions plus récentes de gcc (les devs. de gcc ne maintiennent pas le port OpenBSD pour eux). Ce qui explique qu'ils cherchent une porte de secours...
Sinon, PCC est 13% moins performant que GCC 3.3.5 au benchmark bytebench, ce n'est pas 10% certes, mais ce n'est pas ridicule, surtout à ce stade de son développement, où quelques "low hanging fruits" sont encore à portée de main.
[^] # Re: Alternative ?
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 10.
Mais bon sang, on parle d'un OS d'amateurs, de gens qui développent pour le plaisir, alors oui, Vax est capital, et ils y consacrent du temps. Tu semble ne pas le croire, mais ça l'est vraiment, pour eux, au moins.
En tout cas parler de "marché", fut-ce au figuré, montre où se niche la confusion. C'est précisément là où se trouve le sel des BSD (et certainement où devait être le fun dans le petit monde de Linux avant 1998 environ) : une petite famille, peu de développeurs, tous sont connus, peu de patchs (on peut suivre les changements), bref des projets à taille humaine ; un engouement pour les vieilles machines, du code pour le plaisir du code (ou pour sa beauté, sa simplicité avant son efficacité, par ex.) comme de l'art pour l'art, ou plutôt de l'artisanat, et vraiment rien de corporate. Pas de "marché". GCC pour sa part est touché par l'excès inverse.
D'ailleurs, cette propriété en soi ça suffit à expliquer ce travail sur PCC (bien que ça ne soit pas la seule raison) : même s'il est probable que ça fasse un compilateur plus lent et moins complet, il y a un certain nombre de développeurs qui ont envie de mettre les mains dans les entrailles d'un compilateur au code clean et à dimension humaine. Juste pour le plaisir du bricolage, de l'amateurisme éclairé.
[^] # Re: Historique : y a quand même des fautes qui passent mal pour un jour
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 6.
> Apple a contribué au support d'Objective-C dans GCC alors que si il était possible
> d'avoir un GCC très modulaire il est fort probable (euphémisme pour "plus que certain")
> que le support d'Objective-C serait resté purement dans le giron d'Apple.
C'est marrant que prenne cet exemple, parce que Apple, qui est le principal contributeur de LLVM (qu'ils "donnent" gratuitement donc), a montré qu'on peux faire un compilateur modulaire, sous licence BSD, et auquel des boites peuvent contribuer sans radinerie mesquine. LLVM est le parfait contre-exemple de la théorie politique de GCC.
[^] # Re: PCC concurrent de GCC ?
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 5.
[^] # Re: pas tout jeune
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 5.
Parce que c'est bien trop lent de toutes façons (la différence avec ou sans optims est minimale).
Le projet OpenBSD se fait fort de compiler ses binaires pour toutes les architectures supportées (y compris de _très vieilles archis_) sur la plateforme elle-même. Ce qui évite par ex. de faire comme les devs NetBSD, qui s'aperçoivent parfois des mois après qu'une archi est cassé parce que ça passait bien à la cross-compilation... Et ça permet de stress tester le noyau en cours de développement sur ces architectures : c'est de l'intégration continue, en somme. Évidemment ça marche moins bien quand on a un compilo lent et mal supporté (mal supporté : sur l'archi/plateforme en question, comme tu semble ne pas comprendre...).
[^] # Re: Alternative ?
Posté par herodiade . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 10.
[...]
> Dire qu'on soutient PCC car on trouve que GCC n'est pas maintenu c'est grotesque.
Il apparait que TdR en sait un poil plus long que toi sur les compilos et la façon dont ils sont maintenus. Un boût de phrase, évident mais implicite t'aurait sans doute aidé à comprendre ce dont parle Théo : il n'est pas assez maintenu ... pour les choses qui importent à OpenBSD.
En l'occurrence, OpenBSD se traine sur certaines plateformes un vieux gcc 2.95 (et les autres sont restées en 3.3, d'ailleurs) parce que support par le gcc "upstream" a été délaissé. Le support pour la plateforme OpenBSD est lui aussi, bien entendu, à la charge des devs OpenBSD : les grosses boites qui paient des développeurs à plein temps pour améliorer gcc n'ont que fiche des OpenBSD sur Vax et archis pour bricoleur dinosaures. Le m68k n'est sans doute plus assez corporate. Ces grosses boites font évoluer le logiciel, très vite (ce qui est d'autant plus dur à suivre, du coup), précisément, et l'écart à rattraper pour maintenir les fonctionnalités _qui importent à OpenBSD_ se creuse chaque jour.
Ce mode de fonctionnement est tout à fait justifié de la part de gcc, mais il explique aussi le malaise de certains développeurs qui doivent de facto assurer pendant leurs loisir le maintient d'un code qui change très vite, qui change d'une façon qui ne respecte en rien leurs besoins, un code vieux de 23 ans de patchs accumulés, un code qui est volontairement structuré pour ne pas être modulaire.
[^] # Re: Euh...
Posté par herodiade . En réponse à la dépêche La GNU Free Documentation License 1.3 est publiée. Évalué à 2.
Deux note en complément :
* La notion d'invariants dans la GFDL est très controversée, et conduit par exemple Debian à considérer cette licence comme non libre, ce qui est dommage.
* La GFDL contient un grave "bug" juridique, bien exposé par Bruce Perens ici : http://lwn.net/Articles/305757/ (Johnatan Corbet fait remarquer à ce sujet qu'un simple "chmod -r lefichier" pourrait être illégal sur un un fichier en GFDL, de ce fait).
La cause de ces deux problème est une volonté de bien faire, très louable, mais qui se heurte à la pratique.
Pour donner un exemple concret de quelque chose bien expliqué par baud123 ci-dessus, si je veux ré-utiliser une image en GFDL de commons.wikimedia.org pour faire une carte postale, ou pour imprimer sur un t-shirt, je doit imprimer aussi sur ma carte postale (ou mon t-shirt) le long texte de la licence in extenso, alors qu'une url pourrait avoir la même fonction. Pour cette même raison, l'utilisation de cette licence pour des fichiers audio est encore plus inadaptée. C'est, tout simplement, une licence pour la documentation de logiciels.
Enfin, le choix des wikipédiens ne serait pas trahis par un passage en CC-By-SA. Pour preuve, voici ce qu'ils disent, lorsqu'ils ont le choix des licences (ie. uniquement lors de l'import de fichiers images ou son) :
http://fr.wikipedia.org/wiki/Image:BD-propagande_color_fr.jp(...)
http://fr.wikipedia.org/wiki/Wikipédia:Quelle_licence_utiliser
http://fr.wikipedia.org/wiki/Modèle:Astuce_choisir_une_licence
http://fr.wikipedia.org/wiki/Aide:Importer_sur_Commons_un_fi(...)
http://commons.wikimedia.org/wiki/Commons:Premiers_pas/Sélection_d'une_licence
[^] # Re: Euh...
Posté par herodiade . En réponse à la dépêche La GNU Free Documentation License 1.3 est publiée. Évalué à 2.
[...]
> Si c'était aussi "équivalent", pourquoi limiter :
> - aux "Massive Multiauthor Collaboration Site" et
> - à des dates précises.
La situation de Wikipédia est assez délicate, et spéciale :
* La licence a été choisie par une toute petite poignée de gens (qui, en plus, reconnaissent eux-même avoir mal choisi) et le projet est devenus le projet libre ayant le plus de contributeurs au monde. On ne connais pas encore le choix de licence qui représenterai au mieux le choix des wikipédiens aujourd'hui.
* A été choisie à une époque où il n'y avait pas vraiment d'alternatives, en terme de licences non logicielles.
* A été choisie à une époque où le projet, ses contraintes, ses besoins, etc. étaient encore mal définis. On s'aperçoit maintenant que cette licence correspond à l'esprit du libre souhaité, mais impose certaines contraintes pratiques très peu adaptées, par ex.
* Divers "bugs" juridiques dans la licence sont apparus depuis lors.
* C'est une licence explicitement conçue et adaptée pour la documentation de logiciels, et wikimedia est certainement le plus gros utilisateurs de cette licence tout en ne produisant rien qui ressemble à une documentation de logiciel.
Les nouvelles clauses restreignant qui a ou n'a pas ce droit de re-licencer un contenu GFDL en CC-BY-SA permettent précisément d'empêcher tout autre que la communauté Wikipédia de faire ce choix à leur place. On ne peux pas en profiter pour télécharger un dump actuel de WP dans son coin et le déclarer "CC-By-SA" tout seul.
Aussi la décision de Stallman est tout à fait honorable, à mon sens, et opposée à ta conclusion : il ne s'agit pas de décider à la place des "copyright owners", mais tout au contraire de leur laisser une fenêtre de choix, un laps de temps où ils pourront prendre une décision collective en conscience. Et c'est précisément ce qui est en train de se mettre en place : un large "référendum" entre Wikipédiens est en préparation.
Notez aussi que la FSF est en train de préparer la GFDL 2.0, qui sera conçue et adaptée, car c'est le but de cette licence, pour les manuels de logiciels libres et non les encyclopédies libres. Et on comprends bien que la FSF ne veuille pas se trainer des contraintes hors du champs initial de cette licence simplement parce qu'une poignée de pionniers de wp ont fait un choix un peu trop "léger" (ce qu'ils reconnaissent eux mêmes).
Enfin, le "contrat moral" implicite entre les utilisateurs d'une licence qui choisissent "ou version ultérieur" et la FSF est celui-ci : l'utilisateur est en droit d'attendre que la FSF fera évoluer la licence _en conservant son esprit_. Or à mon sens, si la FSF s'était bornée à copier-coller le texte de la CC-BY-SA in extenso et d'appeler ça "GFDL 1.3", l'esprit de la licence aurait été pleinement conservé. Le changement serait moins radical que, par exemple, le passage de GPLv2 à GPLv3. La FSF a pourtant choisi une mesure encore plus prudente : une astuce permettant à la communauté des "copyright owners" de wikimedia de prendre _leur_ décision à ce sujet. Que pourrais-t-on reprocher à la FSF ?
# Améliorations concernant les non-OpenBSDistes
Posté par herodiade . En réponse à la dépêche OpenBSD 4.4 , The Trial of the BSD Knights. Évalué à 10.
Par exemple, concernant OpenSSH :
- Le sous-système sftp permet désormais de chroot(2)er de force des utilisateurs matchant des règles pré-définies.
- La syntaxe de configuration s'est assouplie : on peux désormais spécifier les adresses au format CIDR dans '.ssh/authorized_keys from="..."', ainsi que les les syntaxe avec négation de d'adresses ou de blocks, comme "Match address 192.0.2.0/24,3ffe:ffff::/32,!10.*" ...
- Très geeky, il y a maintenant une option pour afficher les clefs pub des machines auxquelles on se connecte sous forme d'ASCII art (c'est censé favoriser la reconnaissance des clefs en exploitant la mémoire visuelle, et aider détecter les problèmes)
- Le sous-système sftp s'est vu complété d'émulation des opérations type statvfs(3), et est agrémenté d'une commande "df". Ce qui ne manquera pas d'améliorer les accès sftp depuis les clients émulant un VFS sur SSH (comme gnome-vfs, ou le module FUSE sshfs).