Pour en revenir au sujet c'est sûr qu'un SCV me semble indispensable pour la gestion des lois, et je me demande ce qu'il attende pour en foutre un tellement ça leur révolutionnerait la vie.
Tu veut dire, un de ces logiciels qui permettent d'échanger des fichiers et de faire du travail collaboratif, ce qu'ils viennent juste d'interdire ?
j'ai bien mieux compris les idées importantes de ce sommet en lisant ce résumé
Bah, c'est normal, pour résumer il fallait aller à l'essentiel et synthétiser les détails techniques du texte d'origine ;) En tout cas, merci pour ton encouragement, ça fait plaisir.
J'en profite pour corriger une erreur d'étourderie qui m'a échappée dans la section sur doublefs: « si la première copie, écrite, est endommagée, la première est intacte ». Il faut bien entendu comprendre « la deuxième est intacte » (ou inventer schrödingerfs). Désolé !
Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.
Linux dispose d'un certain nombre de systèmes de fichiers spécifiquement adaptés aux médias tels que la RAM, l'EEPROM etc., comme ramfs, cramfs, tmpfs et surtout jffs2 (http://sources.redhat.com/jffs2/jffs2-html/jffs2-html.html ), mais il ne conviennent pas toujours à un usage généraliste.
Je ne sait pas si JFFS2 est vraiment adapté à la MRAM, que j'ai découvert juste à l'instant, en lisant ton commentaire.
L'accès aux médias physiques est généralement délégué à la couche VFS et aux couche sous-jacentes (SCSI, SATA, ...) mais il faut reconnaître que les FS ne sont pas pour autant totalement dénués de « partis pris » (tendance à privilégier les accès contigus, assomptions sur les caches en mémoire, gestion spéciale des écritures sur les mémoires Flash, ...)
c'est sûr que ça peut surprendre mais je croyais que l'un des bénéfices du libre tout ça c'était qu'on puisse justement subvenir au départ d'un ou du développeur et continuer le projet concerné, par exemple au minimum l'entretenir et fixer les bugs découverts au fur et à mesure ?
Justement, pour pouvoir faire ça, il faut que le code soit maintenable.
À ce titre, au fur et à mesure des engeulades avec Hans Reiser, les devs du kernel ont formulé explicitement des exigences minimales et de bon sens pour l'acceptation d'une grosse nouvelle fonctionalité sensible dans le noyau, car Hans Reiser semblait les ignorer ou les négliger:
- Le code doit respecter les coding standards du noyau (longeur des lignes etc.). Hans Reiser a fait le malin lorsqu'on lui a dit ça: "ouiii mais les coding standards, ça limite ma créativité [...]", mais il devra y passer, comme tout le monde.
- Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
- Le code doit être relu, corrigé et aprouvé par (au moins) un autre expert du domaine (ça permet de remonter des bugs assez tot, et surtout ça fait une nouvelle personne qui connait assez le code pour le maintenir). C'est assez difficile avec le code d'Hans Reiser car celui-ci conteste la moindre remarque, puis monte sur ses grands cheveaux, puis fait le coup du géni incompris ("tu ne peut pas auditer mon code parce que tu est trop imprégné des concepts des fs classiques"), puis fini en attaque personnelles ("tu es un mauvais developpeur", "tu es un idiot", "tu m'en veut personnellement", ...). Si bien que tout les developpeurs qui ont bien voulu aider Reiser en tenant ce role ont finalement déclaré forfait.
- Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
- Facultatif (mais ça accèlere grandement l'inclusion), le code peut être soutenu par un "vendor" (une distribution) qui par ex. essai de l'améliorer, le corriger et l'intègre comme fs par défaut. Malheureusement, les diverses distros qui ont soutenu Hans en tenant ce role pour reiserfs3 sont maintenant échaudées (elles l'on vu se dégager de tout intéret et ne pas participer aux corrections de bugs), et aucune ne semble prete à recommencer pour reiserfs4 (bien qu'Andrew Morton ai formulé cette demande au sujet de reiserfs4 sur lkml).
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
C'est tout comme.
Presque aussitot que reiserfs3 a été intégré dans le noyau, Hans est passé à l'implem de reiserfs4 et a cessé de travailler à la correction de bugs. Cette expérience n'encourage pas les developpeurs à relacher les contraintes que j'ai listé ci-dessus. D'autant que la maintenance des filesystems est une des choses les plus sensibles (on peut abandonner le support d'un driver, mais pas d'un fs), et que reiserfs4 veut "revolutionner" beaucoup de concepts acquis (ce qui l'expose encore plus aux problèmes de maintenabilité potentiels).
Sur ce point, je regrette même que le noyau Linux ai une politique trop lâche par rapport à d'autres OS (les *BSD) où, lorsqu'un dev s'est grillé en incluant du mauvais code ou ne le maintenant pas, il est mis en quarantaine et en tout cas, ne peut plus se permettre de publier des nouveautés wizbang tant qu'il n'a pas corrigé les problèmes. Et dans la culture (et la com: les releases/changelogs/, inteviews, mailing-lists...) ils essaient de mettre plus en avant le travail de ceux qui nettoient et corrigent que de ceux qui ajoutent du code (l'inverse de Linux depuis 2.6 quoi).
Bénéfice secondaire, le newbie qui veut se faire admettre (ou qui cherche la gloire ;) va plutôt chercher à trouver et corriger un nouveau bug qu'à implémenter un quarantième scheduler ; et les utilisateurs de ces systèmes, qui sont dès lors plus sensibilisés à ces questions de qualité de code, ne mettent plus la pression sur les devs pour qu'ils intégrent le dernier fs survendu par le marketing narcissique d'un teuton paranoïaque. La culture qualité, c'est tout bon.
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté. Il a même été question de faire une release uniquement dédiée à la correction du merdier, avec interdiction d'ajouter des fonctionalités.
Je crois qu'il est vraiment temps que Linux devienne exigeant non plus seulement sur la qualité apparement du code, mais sur l'attitude des developpeurs (eg. refuser le nouveau code d'un dev qui a des bugs à corriger, même si ce code parrait bon), pour qu'enfin ces devs se responsabilisent.
En somme, être un logiciel libre n'oblige pas a abandonner tout le travail de qualité logicielle et a accepter n'importe quel patch douteux. C'est le problème avec l'inclusion des produits Reiser...
C'est une belle initiative, et il faut préciser que les améliorations dans DejaVu n'impacteront pas que Fedora: DejaVu est maintenant la police par defaut d'Ubuntu, de l'installeur Debian (etch, sid), de SUSE...
Vu que je n'utilise pas FC, j'ai une question. Puis-je (et: comment ?) aider en ayant à disposition les environements suivants:
- Debian Sarge (fr_FR@UTF-8)
- Ubuntu Dapper (idem)
- Mac OS X 10.4 (japonais + latin1)
Y aurait-il un moyen *simple* d'installer et tester le dernier DejaVu sur l'un ou l'autre de ces environements ?
En bref: le fait de proposer un support ODF externe à MS Office est la meilleur (sinon la seule) façon de désamorcer l'angoument pour ODF, et son risque de popularisation via les institutions (qui le plébicscitent: Maschusset, Belgique).
Plus de risque que l'utilisateur lambda installe spontanément cette extension sur son ordi (donc vous ne pourez jamais compter envoyer des fichiers ODF à quelq'un en esperant qu'il pourra les lire), pas de risque que les administrations à qui l'on impose ODF préfèrent migrer vers OOo et donc qu'elles initient un pool de compétences alternatives à MS Office (ou pire, favorisent des améliorations aux logiciels libres concurents), ...
Tout est dans le mot plug-in. N'y voyez pas un assouplissement de Microsoft quand aux standards ouverts.
Voilà, le fait que ce logiciel ne soit pas appelé à être intégré par défaut dans MS Office est une façon subtile et tactique pour MS de cantonner l'utilisation d'ODF aux fonctionaires sous contraintes légales, et d'empécher la contation.
Dans une interview (publiée hier) du directeur de la société qui édite SoftMaker (une suite bureautique multiplateforme, et plus ou moins compatible ODF) au sujet du support ODF par Microsoft, on a pu lire cet échange prémonitoire: http://www.consortiuminfo.org/standardsblog/article.php?stor(...)
Q: The Massachusetts ITD has issued an RFI asking for information on plugins to facilitate conversions between MS-Office documents and ODF compliant software. Does SoftMaker have any plans to develop and/or bundle any such tools? Did you respond to the RFI? A: No. On the one hand, we don't have the resources to develop such tools. On the other hand I find that this could become counterproductive (for OpenOffice and StarOffice as well) since once such a tool is available people/governments using MS Office may see no longer any reason to think about a switch because they are compatible now to ODF because of that tool. In my opinion it's not a good idea and it should be a job done by Microsoft if they want their software/formats to become compatible. What we will soon release however, is “TextMaker Viewer”, a read-only version of TextMaker that can be distributed freely and that can open, view, and print documents in Microsoft Word, OpenDocument, RTF, HTML, and TextMaker’s own file format.
Résultat, celà à l'air d'une bonne nouvelle, mais dans la pratique:
- On a perdu l'occasion d'un large switch vers OOo dans les administrations (elles resteront sous MS Office, comme elles ont toujours fait).
- On a perdu l'occasion d'imposer ODF comme un format universel: le voilà soudaiement devenu « le format que les ronds de cuir, et eux seuls, sont censés pouvoir accepter si vraiment on le leur demande ».
L'ADAE préconise d'utiliser des formats interopérables (donc généralement des standards ouverts, sauf lorsque celà est en contradiction avec la priorité d'intéropérabilité / large support - ainsi mp3 est préconisé, à juste titre, au détriment de ogg qui est moins universel).
Mais l'ADAE ne préconise en aucun cas d'utiliser des LLs. Elle ne préscrit pas d'implémentation spécifique. C'est bien ce qui lui donne sa légitimité: rester neutre , vendor agnostic, pragmatiques, et centrés uniquement sur l'intéropérabilité. Irréprochable, même par nos ennemis, en somme.
C'est sur ce point que se fourvoient beaucoup de contributeurs du wiki ADAE avec des remarques comme « choisissont le format X, car bien que mal supporté dans la plupart des cas il est poussé (ou : le seul supporté) par le logiciel libre Y »: promouvoir le logiciel libre Y n'est pas la mission d'ADAE.
Cette réthorique décridibilise un peu l'ensemble du travail (qui ne mérite pas ça). Ayez plus confiance dans les LL: si l'intéropérabilité (et rien qu'elle) est privilégiée, ils sauront s'imposer ! De même: les décisions orientées seulement par l'intéret commun public suffiront à promouvoir l'utilisation du logiciel libre, inutile ici de se laisser aller au lobbying bas étage comme nos concurents, qui ne se préoccupent pas du bien commun (« tachons d'imposer la norme / le format que nous supportons le mieux pour tuer nos concurents »), pour une fois qu'un organisme d'état décide de choisir une solution pour d'autres raisons que « les logiciels auquels ont est habitués » ou «les sociétés avec lesquelles on a des partenariats ».
Si l'ADAE déroge à cette neutralité pragmatique, ils offriraient alors aux éditeurs de solutions propriétaire une occasion révée d'invalider leurs décisions comme anti-concurentielles, unfair, etc.
Je comprend mieux le choix de ce moteur de recherche.
Mais pour les problèmes dont tu parle, l'utilisation de Tor par les clients ne serait-elle pas plus indiquée car plus sûre ?
Pour que l'utilisation d'Exalead soit une garantie de confidentialité (au moins au regard des administrations US), il faudrait qu'il remplisse de façon certaine un grand nombre de conditions:
- Qu'il n'ai pas de serveurs www (voir dns) aux US, et que le traffic vers ses serveurs ne passe pas par les US (puisque ce qui arrive au sortir des backbones transatlantiques est toujours susceptible de passer par echellon & cie).
- Idem pour les UK (qui aurait un partenariat avec les US pour son programe echellon): là ça devient difficile ...
- Qu'il ne soit pas de connivence avec des entreprises ou administrations US (fut-ce simplement pour l'utilisation de lien à la adsense).
- Que leurs machines soient diablement sécurisées (pour résiter à la curiosité de la NSA etc).
- Qu'il ne joue pas avec des entreprises de coquins tels qu'EADS
- ...
En tout cas je te remercie de m'avoir fait découvrir cet outil !
Si le modèle de développement libre permet par exemple d'avoir sur le long terme des drivers toujours existant et disponible même pour un vieux périphérique
Mais on ne pourra certainement avoir ce support qu'avec des drivers libres. À la vitesse d'évolution du noyau Linux, ce n'est pas l'initiative Novell qui va changer quoi que ce soit à si long terme...
Et il est absolument clair que les constructeurs ne maintiendront pas des drivers Linux pour leurs vieux matériels bien longtemps (d'autant moins qu'ils ont interet à te vendre du matériel neuf).
pense à firefox sous windows par exemple
Comparaison fallacieuse. Insérer des bouts de libre dans un monde prorio, ce n'est pas la même chose que d'insérer des bouts de proprio dans un logiciel libre.
il y'a pas si longtemps, le problème n'était pas d'avoir un drivers libre, mais un driver tout court
Je n'ai pas le même souvenir que toi. À l'époque de l'ethernet, je branchais mon cable et j'avais le réseau.
À l'époque du Wifi, il faudrait télécharger des drivers binaires d'un coté, des firmwares de l'autre, choisir le kernel qui peut fonctionner avec les deux, s'appercevoir que telle ou telle fonctionalité n'est pas supportée ...
À l'époque des cartes 2D, les fabriquants donnait les specs et les cartes graphiques étaient supportées ; à l'époque de la 3D, ils filent des binaires, et ça marchouille ... parfois.
Et ton approche idéaliste est... ce qui freine l'adoption de Linux par pas mal de gens ;)
Si ce sont les mêmes personnes qui fuient Linux parce qu'il ne ressemble pas à Windows à n'importe quel prix, ce n'est pas une grosse perte, ils ont déjà ce qu'il leur faut, et je suis désolé, l'intéret essentiel de Linux est d'être (de moins en moins certes) un logiciel libre. Avec Mac OS X, ces utilisateurs ont même la possibilité d'utiliser un Unix: quel intéret pour eux d'utiliser un Linux semi-propriétarisé ?
et même pire, ce genre d'attitude est obligatoire dans un environnement d'entreprise... il faut un outil qui fonctionne!
Hu ? En entreprise, on s'en fiche pas mal que la 3D soit accélérée ou pas.
Et pour le reste (pour quasiment tout ce qui ne concerne pas les cartes 3D) on a encore la possibilité de choisir son matériel et de choisir les fabriquants qui jouent le jeux. En tout cas, c'est ce que devrait faire un sysadmin consciencieux.
Et c'est exactement de ça que je parle: chaque fois qu'on a le choix, pourquoi, bon sang, pourquoi accepter de verser de l'argent à ces boites qui se foutent de nous ?
on a pas non plus abordé le problème de propriétés intellectuelles, de copyright, de brevets contenus dans d'éventuels drivers, pas que ce soient de bonne chose... mais à nouveau en étant pragmatique, on ne peut les ignorer...
Parlons en alors. De ces entreprises qui croient que leur propriété intellectuelle tient dans l'interface de dialogue avec les périphériques (ce que documentent les specs, parce qu'on ne demande pas plus, hein, il n'est pas question de les forcer à libérer leur propre code, leur superbe algorithme de consolidation FCC ou je ne sait quoi d'autre).
D'un autre côté, on est tous content de pouvoir faire un urpmi/apt-get/whatevre driver_qui_va_bien sur nos distrib... pour avoir entre autre, de la 3D ;)
Heu, je ne sais pas pour les autres, mais moi, la 3D , bof ...;)
on arrête pas de clamer haut et fort que le logiciel libre, c'est bien, c'est l'avenir du futur, que ça a plein d'avantage... et bien qu'on le montre!
L'absence occasionelle de certains drivers n'anulle pas les autres avantages. Si c'est pour toi le seul point de comparaison, tu trouvera mieux ton compte avec Windows, bien sûr (et on pourrait y venir, avec un noyau dont tout les pilotes sont binaires et closed source).
Il faut bien se rendre compte que le manque de support n'est pas dû à l'incapacité des developpeurs du libre à écrire des bons drivers, mais au fait que certaines sociétés préfèrent livrer des drivers binaires plutot que les specs de leur matériel (nécéssaires pour les developpeurs du libre).
Et mon côté pragmatique me pousse à pense qu'il vaut mieux ça, que rien du tout, ou des drivers ne fonctionnant pas avec la dernière version du kernel.
Le problème c'est précisément ce type d'attidue ou de raisonement (plus encore que l'existence de drivers non libres).
Si tout le monde est « suffisament satisfait » avec des drivers binaires et non libres, comment voulez-vous que l'on soit crédible (ou qu'on puisse faire pression sur les constructeurs) pour réclamer les docs nécéssaires au developpement de drivers libres ?
Comment voulez-vous que des developpeurs soient motivés pour developper de tels drivers (éventuellement par reverse engeneering) si, lorsqu'ils sont un peu moins évolué dans un premier temps, personne ne veut les tester (et donc rapporter des bugs etc) ?
Comment voulez-vous que les fabriquants de chipsets changent de comportement s'ils ne craignent pas un boycote ou une mauvaise image pour leur matériel ?
En bref, ton approche « pragmatique », c'est ce qui freine le support libre du materiel.
Comme c'est Intel qui travaille beaucoup sur la pile wifi générique du noyau Linux, Damien pense que les développeurs ne peuvent pas se permettre de crier et de protester devant la piètre qualité du driver de la carte 3945ABG
Je crois qu'il y a eu un journal ou une dépeche à ce sujet, mais de nombreux developpeurs wifi sous Linux semblent plebisciter le framework wifi alternatif de Devicescape, qui vient d'être totalement libéré.
Il était question d'intégrer cette pile Deviscape -pour le mieux être de chacun- dans le kernel standard, modulo quelques améliorations dans le code actuel: quelqu'un a des nouvelles ? est-ce toujours d'actualité ?
Le support Wifi est globalement OK (certains chipsets ne sont pas supportés, mais ce sont généralement des chipsets relativements peu courants, et pour d'autres le support est à mon goût beaucoup plus carré que sous Linux), pas de suspend to disk/to ram ACPI, pas de bluetooth. Pour moi ce sont des détails donc je trouve que ça roule bien sur un portable.
Si tu veut tout savoir sur le support du matériel sur x86, regarde ici: http://www.openbsd.org/i386.html (et http://www.openbsd.org/macppc.html pour les macs).
Commentaire au sujet du journal: le driver Linux n'utlise pas exactement un « blob opaque qui tourne en espace noyau ». Mais ce driver Linux dépend d'un daemon close source et propriétaire qui tourne en root (et qui cause avec le driver, donc le noyau). Ça, c'était une grande innovation délirante d'Intel, qui avait beaucoup fait jaser, cf. http://kerneltrap.org/node/6270 .
Bref, ce qu'explique Damien Bergamini, c'est que son driver de 3000 lignes fonctionne sans ce daemon propriétaire, qui est nécéssaire au driver Linux (écrit par Intel).
De plus, pour être très précis, on ne peut pas vraiment dire que le driver OpenBSD, pour fonctionner, n'utilise « aucun binaire opaque »: il reste le firmware (binaire, closed source) de la carte à charger à l'intialisation. Mais il est vrai que le firmware ne tourne pas dans le noyau (ni même en userland), il est seulement chargé dans la carte wifi puis exécuté par celle-ci.
La performance de Damien est assez somptueuse, lorsqu'on sait qu'Intel ne lui a pas donné de doc, et qu'il a fait son driver en reverse engeneerant le driver Linux, en trouvant moyen de le réduire au 1/6em en nombre de lignes, de virer la dépendance au daemon root propriétaire, tout ceci en seulement 2 mois après qu'Intel ai publié le driver Linux.
Ce n'est pas le coup d'essai de Damien, il a aussi oeuvré pour les drivers OpenBSD des autres chipsets Wifi Intel, là aussi en reverse engeneerant le driver Linux et en trouvant moyen de le rendre beaucoup plus petit et lisible.
On peut aussi citer son admirable travail pour les chipsets Wifi Ralink (société qui, elle, donne les docs et des firmwares redistribuables): en quelques mois son driver marchait mieux que le driver Linux fournis par Ralink (par comparaison, le projet http://rt2x00.serialmonkey.com de réécriture de ce driver sous Linux patauge depuis presque deux ans sans résultat probant, ce qui montre que ce n'est pas facile).
Sur le lien kerneltrap que je donne ci-dessus, vous pourrez remarquer combien le developpeur kernel Linux Christoph Hellwig a vu juste (et Alan Cox a vu faux), lorsqu'il dit: « If intel doesn't do the right thing support for their hardware will have to wait until someone has reverse-engineered their daemon » !
Ok je regrette, c'etait plus fort que moi, je suis tombé dans le troll des licences. Désolé :(
Celà dit, sortons du troll et revenons aux faits pour parler de cette licence ISC: ce n'est pas inutile, car elle est peu connue.
En fait, Krunch, ce serait plutôt "les deux clauses", seulement.
La licence ISC - préférée par OpenBSD - est identique à la licence BSD « révisée » (que la FSF considère comme l'une des « GPL-Compatible, Free Software Licenses » cf. http://www.fsf.org/licensing/licenses/index_html ) à ceci près que la 3em claus, celle interdisant d'utiliser les noms des auteurs sans consentement écrit, est enlevée, et les 2 clauses restantes sont fusionées en une seule phrase (mais le sens reste identique).
Ça saute aux yeux lorsqu'on les compare en vis à vis:
* La licence ISC :
/*
* Copyright (c) CCYY YOUR NAME HERE <user@your.dom.ain>
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
* La licence BSD révisée :
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.
THE SOFTWARE IS PROVIDED "AS IS" AND [ snip le reste du disclaimer, identique à celui ci-dessus ]
Donc la seule différence est l'absence, dans la licence ISC, de cette 3em clause qui interdit d'utiliser le nom des auteurs sans permission écrite.
À titre d'info, une des motivations du choix de la licence ISC (de préférence à d'autres licences similaires comme BSD ou Apache) souvent exprimée par les developpeurs d'OpenBSD, c'est qu'ils redoutent les licences avec « too much words », exactement comme ils préfèrent les programmes simples ou avec peu de code, dont ils peuvent en comprendre tout les détails clairement et sans ambiguité (surtout que dans le cas des licences: ils n'ont sans doute pas de conseillés juridiques atitrés sous la main, à la différence peut-être des grosses distros etc.).
Quand à leur position sur la réutilisation du code, elle est bien exprimée - avec tout le langage fleuri qui fait le charme de Theo de Raadt - dans ce commit historique: http://www.monkey.org/openbsd/archive/source-changes/0105/ms(...)
But software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.
Julien: si, si, on peut "sub licencer" le logiciel ; la licence prescrit seulement que ce texte doit apparaitre quelque part dans le soft redistribué, mais pas qu'il doit s'appliquer au soft ou que le soft doit etre redistribué sous ces termes.
Ainsi, le site d'OpenBSD précise: « The Berkeley copyright poses no restrictions on private or commercial use of the software and imposes only simple and uniform requirements for maintaining copyright notices in redistributed versions and crediting the originator of the material only in advertising. ». (page http://www.openbsd.org/policy.html ).
C'est pour ça qu'on peut utiliser le code ISC ou BSD rev. pour faire du propriétaire ou du GPL etc.
Et c'est pour ça que la FSF dit « The X11 [MIT] license and the revised BSD license are more or less equivalent. ».
Voir l'explication très claire sur les licences ici: http://www.openbsd.org/policy.html
Et éventuellement la description des objectifs ici: http://www.openbsd.org/goals.html
(en particulier, le "goal" suivant: « Integrate good code from any source with acceptable copyright (ISC or Berkeley style preferred, GPL acceptable as a last recourse but not in the kernel, NDA never acceptable). We want to make available source code that anyone can use for ANY PURPOSE, with no restrictions. We strive to make our software robust and secure, and encourage companies to use whichever pieces they want to. »).
Voilou, j'espère avoir clarifié la question des licences BSD rev. et ISC hors de tout troll cette fois ! ;)
Note que cette licence permet aussi aux programmes GPL de réutiliser le code BSD, ou de se linker sur des libs BSD. C'est au moins aussi courant que la réutilsation de code BSD dans des logiciels proprios, et ça profite à tout le monde.
D'où mon message ci-dessus. Par exemple, leur strlcat.c et strlcpy.c sont récupérés tels quels par plein de trucs, dont PHP, MySQL, Solaris, FreeBSD, Mac OSX, kde-libs, rsync, nmap, dans le noyau Linux, .... Donc le fait que des logiciels propriétaires l'utilisent est un moindre mal par rapport aux bénéfices (et on ne vas pas se priver de tant de bonheur à cause des softs proprios ! ;)
La BSD (ou ISC, qui est en fait maintenant le choix préféré des devs OpenBSD) est compatible avec la GPL, mais la GPL n'est pas compatible avec la BSD (ou ISC, ou MIT, ou CDDL etc.). Sur un plan de compatibilité technique et du partage du code entre utilisateurs de libre: 1 à 0.
Faut dire qu'on n'est pas étouffé par le feedback des gens de la DGME.
Cf. leur effacement de toutes les modifications des règles (avec perte des modifs !) ... un mois après l'ouverture publique du wiki (au lieu d'avoir pris la peine d'expliquer tout de suite aux contributeurs qu'il ne fallait pas modifier directement les règles). Ils ont l'air d'oublier qu'on est arrivé devant un large corpus de règles toutes faites sans avoir la moindre idée des discussions et problématiques qui y ont amené.
Ça n'encourage pas à contribuer, l'impression de travailler dans le vide (ne pas savoir si ce qu'on fait est ne serait-ce que vaguement utile ou complétement à coté de la plaque). D'ailleur j'ai l'impression que beaucoup de débats ont vaguement viré au troll, voir au "choix de la norme obscure mais ayant une implémentation libre" (or l'objectif est l'intéroperabilité, pas le choix politique du libre vs. pas libre) sans que les types qui connaissent les objectifs, la DGME, se donnent la peine de recadrer ou expliquer les orientations, de commenter l' "utilisabilité" ou pas de tel ou tel type de contribution etc.).
De mémoire: TdR avait annoncé que la dette d'OpenBSD s'élevait a peut près à 40 000$, soit environ la somme des subventions dont tu parle.
On peut donc supposer qu'ils se sont désendétté, mais ce serait vraiment bien qu'il y ai d'autres contribution pour aller au-delà (financer les hackatons, leurs grosses consomation en éléctricité, ou un developpeur à plein temps pendant quelques mois etc.).
Rappelons qu'OpenBSD est un des rares, sinon le seul, OS libres à n'être pas fortement souvenu par des grosses sociétés: FreeBSD et NetBSD sont respectivement largement subventionés (Wasabi etc.), Fedora, Ubuntu et Suse aussi bien sûr, Debian a des developpeurs payés à plein temps par de nombreuses sociétés (Ubuntu, Progeny, Xandros etc.) (et d'une façon générale, les gros fabriquants de chipsets subentionent ou développent souvent eux-même les drivers pour le noyau Linux, ce qui n'est pas le cas pour OpenBSD).
Le travail du projet OpenBSD est utile à tous, même ceux qui n'utilisent pas cet OS. Outre le developpement d'OpenSSH (et autres logiciels portées ailleur comme OpenNTPD, OpenBGPD, OpenOSPFD, ISAKMPD, pf, carp ou systrace), ne pas oublier que:
- Leur audit permanent des logiciels dans le système de base leur permet d'envoyer de nombreux patches de renforcement de la sécurité upstream (apache /mod_ssl, sendmail, tcpdump, perl ...). Un travail d'autant plus utile qu'il est rarement fait par les autres OS (audit et ré-audit du code ligne par ligne, re scan du code à chaque nouveau type de faille ou technique d'attaque découverte ...).
- Ils prennent régulièrement le temps d'écrire des APIs portables qui facilitent la programation sécurisée (strlcat, strlcpy, strtonum, arc4random ...), et/ou de documenter les bonnes pratiques en matière de prog C sécurisée (en tirant parti de leur expérience de 10 ans d'audit).
- Leur engagement pour la liberté du code et des drivers, à coté de la FSF (mais en plus activiste) a souvent porté ses fruits (ouverture des spécifications de matériel, droits de redistribution de firmwares ...).
- Leur experience de pionniers sur certaines technologies de sécurisation permet de faire gagner du temps et éviter des bugs aux autres lorsqu'ils implémentent ultérierement une techno similaire (par ex. leur expérience en crypto avant que les US en autorisent l'exportation, ou l'utilisation de propolice et W^X qui a permis de corriger de nombreux bugs dans les applis userland et donc faciliter l'utilisation de la fonctionalité equivalente dans les distros Linux, leur support des plateformes 64bits en natif (pas d'emulation 32bits sur arch 64bits) qui a aussi levé plein de bugs, ou simplement de démontrer la faisabilité etc...
En somme, et même s'ils sont une "niche" dans l'ecosysteme des OS, leur travail est très bénéfique pour la qualité des distributions GNU/Linux.
Or ils ont encore besoin d'argent, et si vous pouvez les aider, par exemple en achetant un CD ou en faisant un don, ça ne sera pas de l'argent fichu en l'air.
Suis-je le seul à trouver très étrange que les opérateurs comptent sur le bridage des clients pour assurer la sécurité de leurs réseaux ?
S'ils comptent réelement là dessus, ils vont avoir, tôt ou tard, des mauvaises surprises (dès que les bidouilleurs s'intéresseront a leurs systèmes). C'est un peu comme si la sécurité de mes serveurs webs était implémentée dans des restrictions de firefox !
Pour revenir au téléphone en question, je ne sait pas vous, mais je le trouve assez light pour un téléphone "high end" "nécéssitant un véritable OS": pas d'UMTS, pas de 3G, pas de Wifi, pas de VoIP, pas de navigateur www, pas de lecteur CF/SD, une autonomie médiocre ... bref, ses caractéristiques ne semblent pas dépasser les traditionels symbian sur nokia d'il y a deux ans. Pas du tout ce que j'attendrai d'un smartphone sous Linux !
Ah ok, merci beaucoup pour l'explication poitue, je comprend (un peu) mieux.
En lisant ta réponse j'ai quand même gardé cette question en tête, en pensant (à tord ou à raison ?) que ce genre de « split » (comme LG, mais aussi pour les autres familles) serai une réponse pragmatique :
- Un contournement des bugs et limitations des logiciels dont tu parle (Pango, Qt, et peut-être d'autres ? - si on veut utiliser DejaVu sur d'autres OS, eg. en l'incluant dans un fichier ps, odf ou pdf ? et lorsque les bugs seront corrigés: la rétro-compatibilité avec les vieilles versions bugguées ?). Si j'ai compris ce que tu expliquais, le parti pris actuel semble être assez exigeant, et aurai tendance à butter sur les bugs des libs sous-jacentes (est-ce souhaitable ?)
- Une certaine souplesse pour l'utilisateur dans le choix de ses polices (même sans parler des « styles » comme ci-dessus). Comme DejaVu LG lui permet déjà de choisir la meilleure pour les scripts latins (et une autre pour des scripts différents où DV n'est pas la meilleure), on pourrai imaginer qu'un autre utilisateur souhaiterai utiliser DV pour afficher l'arabe et autre chose pour l'ASCII/latin, et encore autre chose pour ses formules mathématiques. De plus, lorsque la couverture d'une écriture par DV est légèrement incomplète, ce serait peut-être une solution temporaire pour qu'un utilisateur de cette écriture puisse basculer facilement vers un support complet mais moins beau, si cette incomplétude le gène trop ?
- La question du poid et de l'utilisation des ressources (à tout niveaux: poid en mémoire, sur le disque, téléchargements/updates, ...) qui reste effective, surtout si DejaVu est susceptible de progresser très vite et de couvrir de très nombreuses écritures, ou lorsqu'on veut l'utiliser pour de l'embarqué (PDA en Arabe, téléphone en Coréen, OLPC en Afrique ...), ou incluse dans des documents qu'on redistribue.
Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais), un utilisateur arabophone aura le dilemne entre choisir DV LG + une autre police pour l'Arabe, ou DejaVu normal et une grosse utilisation de ressources ; réciproquement pour un utilisateur Japonophone. Une famille de polices façon "DejaVU LG", "DejaVu Arabic", "DejaVu Kanjis", "DejaVu Kanas", ... leur permetrai de choisir les composants qui les intéressse, non ? D'autre part, le calcul du rendu des chaines ne risque-t-il pas d'être ralenti si Pango & co ont besoin de parcourir, à chaque caractère, un grand nombre de glyphes pour trouver celui qu'il doit afficher ?
Est-ce que je me gourre / suis tout à fait à coté de la plaque ?
Et aussi, du coup, si la position des développeurs de DejaVu a été de proposer une version LG réduite aux caractères latins, est-ce que leur position sera aussi de proposer des versions réduites de ce type pour les caractères Arabes etc. ? Quels sont les avantages de distribuer, comme aujoud'hui, tout en un (avec seulement une possibilité de choix pour les caractères de DejaVu LG) ?
Sur le sujet de la pertinence d'inclure tout (y compris les scripts non latins) dans la même version de DejaVu (plutôt que de faire, par exemple, une "DejaVu Arabic"), il y a un gros débat ici:
Notez que les participants au débat (Behdad Esfahbod, Owen Taylor etc.) sont vraiment des core-hackers de gnome ou x.org, et savent de quoi ils parlent.
En bref: ils pense que c'est pas un choix pertinent, qu'il faudrait plutôt spliter DejaVu et la question de poid en mémoire n'est pas le seul problème (cf. l'exemple dans le commentaire #27).
Un exemple de problème intéréssant soulevé par Behdad, c'est que cette approche l'empêche d'utiliser DejaVu pour les scripts latins et choisir simultanément une police rendant correctement les caractères Arabes à la façon Perse (puisque le tout en un DejaVu contraint l'utilisation d'un seul type de glyphe pour un caractère donné).
Une conséquence dommage, c'est que DejaVu était bien présentie pour être la font par defaut de plusieurs distributions, et celles-ci (à ma connaissance, Ubuntu et Fedora) sont en train de revenir d'urgence sur Bitstream, à cause des problèmes induits par l'approche "all in one" (et de certains bugs non corrigés dans DejaVu).
cf. par ex. https://launchpad.net/distros/ubuntu/+source/fontconfig/+bug(...)
Quelle est la position des developpeurs de DejaVu concernant cette question ? envisagent-ils de splitter DejaVu pour les scripts non latins ?
Les gens de chez FreeBSD ont obtenu le droit de faire et distribuer un port.
Par contre il semblerait que l'ouverture dont parle la dépeche, le droit d'intégréer Java dans un OS (de le patcher légèrement, le packager et le redistribuer) ne soit accordé qu'aux distros de Linux et Solaris.
Bah la définition de l'OSI n'est en rien une référence. C'est une position idéologique, que tout le monde n'adopte pas.
Du coup ce mot est utilisé avec des acceptions fort différentes, et c'est bien le problème: certains en profitent pour faire du PR en ventant leur logiciel comme "open source" alors qu'il n'est pas libre.
En l'occurence, c'est exactement ce que Sun a fait dans l'exemple du post auquel je répond: preuve qu'il y a un probleme avec ce terme.
Le terme "logiciel libre" (ou en anglais, pour un maximum de clarté, "free and open source software", ou "free software, in the FSF meaning") n'a pas ce genre d'ambiguité, et ne permet pas de telles jongleries marketing (je n'ai jamais vu un éditeur vanter son logiciel propriétaire en disant qu'il est un "logiciel libre").
Leur annonces successives (c'est pas la première) de « nous allons rendre Java Open Source » sont toujours relayées par les journalistes (et même les moules de dlfp ;) alors que c'est un scoop avarié :
- Java est déjà open source (oui, on peut avoir accès aux sources)
- Java n'est pas libre, c'est ça qui pose problème.
Bref, je ne suis pas certain qu'on puisse attendre beaucoup des executives de Sun tant qu'ils continueront à faire cette confusion , opensource / logiciel libre.
Comment peuvent-ils remedier à un problème qu'ils ne comprennent pas bien (ou font semblant de ne pas comprendre) ?
Ils disent vouloir « rendre java opensource tout en empéchant les forks » : je vois mal comment on peut fairer un logiciel libre (librement modifiable, librement redistribuable) avec une telle contrainte. Une idée ?
millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.
Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)
Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.
En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.
D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).
et permet aussi de sortir d'une machine virtuelle Xen.
Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.
[^] # Re: L'intéropérabilité
Posté par herodiade . En réponse au journal Il leur faudrait un système de gestion de version. Évalué à 7.
Tu veut dire, un de ces logiciels qui permettent d'échanger des fichiers et de faire du travail collaboratif, ce qu'ils viennent juste d'interdire ?
[^] # Re: Bravo !
Posté par herodiade . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 10.
Bah, c'est normal, pour résumer il fallait aller à l'essentiel et synthétiser les détails techniques du texte d'origine ;) En tout cas, merci pour ton encouragement, ça fait plaisir.
J'en profite pour corriger une erreur d'étourderie qui m'a échappée dans la section sur doublefs: « si la première copie, écrite, est endommagée, la première est intacte ». Il faut bien entendu comprendre « la deuxième est intacte » (ou inventer schrödingerfs). Désolé !
Nos fs tiennent comptent des caractéristiques habituelles des disques durs (cylindres, pistes, rotation....etc) qui n'ont plus aucune importance dans ce cas.
Linux dispose d'un certain nombre de systèmes de fichiers spécifiquement adaptés aux médias tels que la RAM, l'EEPROM etc., comme ramfs, cramfs, tmpfs et surtout jffs2 (http://sources.redhat.com/jffs2/jffs2-html/jffs2-html.html ), mais il ne conviennent pas toujours à un usage généraliste.
Je ne sait pas si JFFS2 est vraiment adapté à la MRAM, que j'ai découvert juste à l'instant, en lisant ton commentaire.
L'accès aux médias physiques est généralement délégué à la couche VFS et aux couche sous-jacentes (SCSI, SATA, ...) mais il faut reconnaître que les FS ne sont pas pour autant totalement dénués de « partis pris » (tendance à privilégier les accès contigus, assomptions sur les caches en mémoire, gestion spéciale des écritures sur les mémoires Flash, ...)
[^] # Re: De la maintenance..
Posté par herodiade . En réponse à la dépêche Pourquoi Reiser4 n'est toujours pas intégré à Linux. Évalué à 10.
Justement, pour pouvoir faire ça, il faut que le code soit maintenable.
À ce titre, au fur et à mesure des engeulades avec Hans Reiser, les devs du kernel ont formulé explicitement des exigences minimales et de bon sens pour l'acceptation d'une grosse nouvelle fonctionalité sensible dans le noyau, car Hans Reiser semblait les ignorer ou les négliger:
- Le code doit respecter les coding standards du noyau (longeur des lignes etc.). Hans Reiser a fait le malin lorsqu'on lui a dit ça: "ouiii mais les coding standards, ça limite ma créativité [...]", mais il devra y passer, comme tout le monde.
- Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
- Le code doit être relu, corrigé et aprouvé par (au moins) un autre expert du domaine (ça permet de remonter des bugs assez tot, et surtout ça fait une nouvelle personne qui connait assez le code pour le maintenir). C'est assez difficile avec le code d'Hans Reiser car celui-ci conteste la moindre remarque, puis monte sur ses grands cheveaux, puis fait le coup du géni incompris ("tu ne peut pas auditer mon code parce que tu est trop imprégné des concepts des fs classiques"), puis fini en attaque personnelles ("tu es un mauvais developpeur", "tu es un idiot", "tu m'en veut personnellement", ...). Si bien que tout les developpeurs qui ont bien voulu aider Reiser en tenant ce role ont finalement déclaré forfait.
- Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
- Facultatif (mais ça accèlere grandement l'inclusion), le code peut être soutenu par un "vendor" (une distribution) qui par ex. essai de l'améliorer, le corriger et l'intègre comme fs par défaut. Malheureusement, les diverses distros qui ont soutenu Hans en tenant ce role pour reiserfs3 sont maintenant échaudées (elles l'on vu se dégager de tout intéret et ne pas participer aux corrections de bugs), et aucune ne semble prete à recommencer pour reiserfs4 (bien qu'Andrew Morton ai formulé cette demande au sujet de reiserfs4 sur lkml).
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
C'est tout comme.
Presque aussitot que reiserfs3 a été intégré dans le noyau, Hans est passé à l'implem de reiserfs4 et a cessé de travailler à la correction de bugs. Cette expérience n'encourage pas les developpeurs à relacher les contraintes que j'ai listé ci-dessus. D'autant que la maintenance des filesystems est une des choses les plus sensibles (on peut abandonner le support d'un driver, mais pas d'un fs), et que reiserfs4 veut "revolutionner" beaucoup de concepts acquis (ce qui l'expose encore plus aux problèmes de maintenabilité potentiels).
Sur ce point, je regrette même que le noyau Linux ai une politique trop lâche par rapport à d'autres OS (les *BSD) où, lorsqu'un dev s'est grillé en incluant du mauvais code ou ne le maintenant pas, il est mis en quarantaine et en tout cas, ne peut plus se permettre de publier des nouveautés wizbang tant qu'il n'a pas corrigé les problèmes. Et dans la culture (et la com: les releases/changelogs/, inteviews, mailing-lists...) ils essaient de mettre plus en avant le travail de ceux qui nettoient et corrigent que de ceux qui ajoutent du code (l'inverse de Linux depuis 2.6 quoi).
Bénéfice secondaire, le newbie qui veut se faire admettre (ou qui cherche la gloire ;) va plutôt chercher à trouver et corriger un nouveau bug qu'à implémenter un quarantième scheduler ; et les utilisateurs de ces systèmes, qui sont dès lors plus sensibilisés à ces questions de qualité de code, ne mettent plus la pression sur les devs pour qu'ils intégrent le dernier fs survendu par le marketing narcissique d'un teuton paranoïaque. La culture qualité, c'est tout bon.
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté. Il a même été question de faire une release uniquement dédiée à la correction du merdier, avec interdiction d'ajouter des fonctionalités.
Je crois qu'il est vraiment temps que Linux devienne exigeant non plus seulement sur la qualité apparement du code, mais sur l'attitude des developpeurs (eg. refuser le nouveau code d'un dev qui a des bugs à corriger, même si ce code parrait bon), pour qu'enfin ces devs se responsabilisent.
En somme, être un logiciel libre n'oblige pas a abandonner tout le travail de qualité logicielle et a accepter n'importe quel patch douteux. C'est le problème avec l'inclusion des produits Reiser...
# Comment participer lorsqu'on n'utilise pas Fedora Core ?
Posté par herodiade . En réponse à la dépêche Fedora lance une campagne de test de la police DejaVu. Évalué à 1.
Vu que je n'utilise pas FC, j'ai une question. Puis-je (et: comment ?) aider en ayant à disposition les environements suivants:
- Debian Sarge (fr_FR@UTF-8)
- Ubuntu Dapper (idem)
- Mac OS X 10.4 (japonais + latin1)
Y aurait-il un moyen *simple* d'installer et tester le dernier DejaVu sur l'un ou l'autre de ces environements ?
# Le coup fourré de Microsoft
Posté par herodiade . En réponse à la dépêche Microsoft se met à l'Open Document. Évalué à 7.
http://www.groklaw.net/article.php?story=20060706064747376
En bref: le fait de proposer un support ODF externe à MS Office est la meilleur (sinon la seule) façon de désamorcer l'angoument pour ODF, et son risque de popularisation via les institutions (qui le plébicscitent: Maschusset, Belgique).
Plus de risque que l'utilisateur lambda installe spontanément cette extension sur son ordi (donc vous ne pourez jamais compter envoyer des fichiers ODF à quelq'un en esperant qu'il pourra les lire), pas de risque que les administrations à qui l'on impose ODF préfèrent migrer vers OOo et donc qu'elles initient un pool de compétences alternatives à MS Office (ou pire, favorisent des améliorations aux logiciels libres concurents), ...
Tout est dans le mot plug-in. N'y voyez pas un assouplissement de Microsoft quand aux standards ouverts.
Voilà, le fait que ce logiciel ne soit pas appelé à être intégré par défaut dans MS Office est une façon subtile et tactique pour MS de cantonner l'utilisation d'ODF aux fonctionaires sous contraintes légales, et d'empécher la contation.
Dans une interview (publiée hier) du directeur de la société qui édite SoftMaker (une suite bureautique multiplateforme, et plus ou moins compatible ODF) au sujet du support ODF par Microsoft, on a pu lire cet échange prémonitoire: http://www.consortiuminfo.org/standardsblog/article.php?stor(...)
Résultat, celà à l'air d'une bonne nouvelle, mais dans la pratique:
- On a perdu l'occasion d'un large switch vers OOo dans les administrations (elles resteront sous MS Office, comme elles ont toujours fait).
- On a perdu l'occasion d'imposer ODF comme un format universel: le voilà soudaiement devenu « le format que les ronds de cuir, et eux seuls, sont censés pouvoir accepter si vraiment on le leur demande ».
[^] # Re: L'ADAE préconise déjà d'utiliser des LLs mais...
Posté par herodiade . En réponse à la dépêche Important appel d'offres du ministère de l'intérieur. Évalué à 7.
L'ADAE préconise d'utiliser des formats interopérables (donc généralement des standards ouverts, sauf lorsque celà est en contradiction avec la priorité d'intéropérabilité / large support - ainsi mp3 est préconisé, à juste titre, au détriment de ogg qui est moins universel).
Mais l'ADAE ne préconise en aucun cas d'utiliser des LLs. Elle ne préscrit pas d'implémentation spécifique. C'est bien ce qui lui donne sa légitimité: rester neutre , vendor agnostic, pragmatiques, et centrés uniquement sur l'intéropérabilité. Irréprochable, même par nos ennemis, en somme.
C'est sur ce point que se fourvoient beaucoup de contributeurs du wiki ADAE avec des remarques comme « choisissont le format X, car bien que mal supporté dans la plupart des cas il est poussé (ou : le seul supporté) par le logiciel libre Y »: promouvoir le logiciel libre Y n'est pas la mission d'ADAE.
Cette réthorique décridibilise un peu l'ensemble du travail (qui ne mérite pas ça). Ayez plus confiance dans les LL: si l'intéropérabilité (et rien qu'elle) est privilégiée, ils sauront s'imposer ! De même: les décisions orientées seulement par l'intéret commun public suffiront à promouvoir l'utilisation du logiciel libre, inutile ici de se laisser aller au lobbying bas étage comme nos concurents, qui ne se préoccupent pas du bien commun (« tachons d'imposer la norme / le format que nous supportons le mieux pour tuer nos concurents »), pour une fois qu'un organisme d'état décide de choisir une solution pour d'autres raisons que « les logiciels auquels ont est habitués » ou «les sociétés avec lesquelles on a des partenariats ».
Si l'ADAE déroge à cette neutralité pragmatique, ils offriraient alors aux éditeurs de solutions propriétaire une occasion révée d'invalider leurs décisions comme anti-concurentielles, unfair, etc.
# Chine != Japon
Posté par herodiade . En réponse au journal Hasta la victoria : Sempre?. Évalué à 10.
Je pense que tu voulais dire « l'empire du milieu » non ?
[^] # Re: dommage pour le moteur..
Posté par herodiade . En réponse à la dépêche Mise à jour de la documentation de Postfix en français. Évalué à 2.
Mais pour les problèmes dont tu parle, l'utilisation de Tor par les clients ne serait-elle pas plus indiquée car plus sûre ?
Pour que l'utilisation d'Exalead soit une garantie de confidentialité (au moins au regard des administrations US), il faudrait qu'il remplisse de façon certaine un grand nombre de conditions:
- Qu'il n'ai pas de serveurs www (voir dns) aux US, et que le traffic vers ses serveurs ne passe pas par les US (puisque ce qui arrive au sortir des backbones transatlantiques est toujours susceptible de passer par echellon & cie).
- Idem pour les UK (qui aurait un partenariat avec les US pour son programe echellon): là ça devient difficile ...
- Qu'il ne soit pas de connivence avec des entreprises ou administrations US (fut-ce simplement pour l'utilisation de lien à la adsense).
- Que leurs machines soient diablement sécurisées (pour résiter à la curiosité de la NSA etc).
- Qu'il ne joue pas avec des entreprises de coquins tels qu'EADS
- ...
En tout cas je te remercie de m'avoir fait découvrir cet outil !
[^] # Re: Bof...
Posté par herodiade . En réponse à la dépêche Sortie et test de SUSE 10.1. Évalué à 10.
Par exemple, à point nommé pour la comparaison: http://linuxfr.org/~patrick_g/21744.html
Si le modèle de développement libre permet par exemple d'avoir sur le long terme des drivers toujours existant et disponible même pour un vieux périphérique
Mais on ne pourra certainement avoir ce support qu'avec des drivers libres. À la vitesse d'évolution du noyau Linux, ce n'est pas l'initiative Novell qui va changer quoi que ce soit à si long terme...
Et il est absolument clair que les constructeurs ne maintiendront pas des drivers Linux pour leurs vieux matériels bien longtemps (d'autant moins qu'ils ont interet à te vendre du matériel neuf).
pense à firefox sous windows par exemple
Comparaison fallacieuse. Insérer des bouts de libre dans un monde prorio, ce n'est pas la même chose que d'insérer des bouts de proprio dans un logiciel libre.
il y'a pas si longtemps, le problème n'était pas d'avoir un drivers libre, mais un driver tout court
Je n'ai pas le même souvenir que toi. À l'époque de l'ethernet, je branchais mon cable et j'avais le réseau.
À l'époque du Wifi, il faudrait télécharger des drivers binaires d'un coté, des firmwares de l'autre, choisir le kernel qui peut fonctionner avec les deux, s'appercevoir que telle ou telle fonctionalité n'est pas supportée ...
À l'époque des cartes 2D, les fabriquants donnait les specs et les cartes graphiques étaient supportées ; à l'époque de la 3D, ils filent des binaires, et ça marchouille ... parfois.
Et ton approche idéaliste est... ce qui freine l'adoption de Linux par pas mal de gens ;)
Si ce sont les mêmes personnes qui fuient Linux parce qu'il ne ressemble pas à Windows à n'importe quel prix, ce n'est pas une grosse perte, ils ont déjà ce qu'il leur faut, et je suis désolé, l'intéret essentiel de Linux est d'être (de moins en moins certes) un logiciel libre. Avec Mac OS X, ces utilisateurs ont même la possibilité d'utiliser un Unix: quel intéret pour eux d'utiliser un Linux semi-propriétarisé ?
et même pire, ce genre d'attitude est obligatoire dans un environnement d'entreprise... il faut un outil qui fonctionne!
Hu ? En entreprise, on s'en fiche pas mal que la 3D soit accélérée ou pas.
Et pour le reste (pour quasiment tout ce qui ne concerne pas les cartes 3D) on a encore la possibilité de choisir son matériel et de choisir les fabriquants qui jouent le jeux. En tout cas, c'est ce que devrait faire un sysadmin consciencieux.
Et c'est exactement de ça que je parle: chaque fois qu'on a le choix, pourquoi, bon sang, pourquoi accepter de verser de l'argent à ces boites qui se foutent de nous ?
on a pas non plus abordé le problème de propriétés intellectuelles, de copyright, de brevets contenus dans d'éventuels drivers, pas que ce soient de bonne chose... mais à nouveau en étant pragmatique, on ne peut les ignorer...
Parlons en alors. De ces entreprises qui croient que leur propriété intellectuelle tient dans l'interface de dialogue avec les périphériques (ce que documentent les specs, parce qu'on ne demande pas plus, hein, il n'est pas question de les forcer à libérer leur propre code, leur superbe algorithme de consolidation FCC ou je ne sait quoi d'autre).
[^] # Re: Bof...
Posté par herodiade . En réponse à la dépêche Sortie et test de SUSE 10.1. Évalué à 10.
Heu, je ne sais pas pour les autres, mais moi, la 3D , bof ...;)
on arrête pas de clamer haut et fort que le logiciel libre, c'est bien, c'est l'avenir du futur, que ça a plein d'avantage... et bien qu'on le montre!
L'absence occasionelle de certains drivers n'anulle pas les autres avantages. Si c'est pour toi le seul point de comparaison, tu trouvera mieux ton compte avec Windows, bien sûr (et on pourrait y venir, avec un noyau dont tout les pilotes sont binaires et closed source).
Il faut bien se rendre compte que le manque de support n'est pas dû à l'incapacité des developpeurs du libre à écrire des bons drivers, mais au fait que certaines sociétés préfèrent livrer des drivers binaires plutot que les specs de leur matériel (nécéssaires pour les developpeurs du libre).
Et mon côté pragmatique me pousse à pense qu'il vaut mieux ça, que rien du tout, ou des drivers ne fonctionnant pas avec la dernière version du kernel.
Le problème c'est précisément ce type d'attidue ou de raisonement (plus encore que l'existence de drivers non libres).
Si tout le monde est « suffisament satisfait » avec des drivers binaires et non libres, comment voulez-vous que l'on soit crédible (ou qu'on puisse faire pression sur les constructeurs) pour réclamer les docs nécéssaires au developpement de drivers libres ?
Comment voulez-vous que des developpeurs soient motivés pour developper de tels drivers (éventuellement par reverse engeneering) si, lorsqu'ils sont un peu moins évolué dans un premier temps, personne ne veut les tester (et donc rapporter des bugs etc) ?
Comment voulez-vous que les fabriquants de chipsets changent de comportement s'ils ne craignent pas un boycote ou une mauvaise image pour leur matériel ?
En bref, ton approche « pragmatique », c'est ce qui freine le support libre du materiel.
# stack ieee80211
Posté par herodiade . En réponse au journal Driver wifi pour OpenBSD. Évalué à 3.
Je crois qu'il y a eu un journal ou une dépeche à ce sujet, mais de nombreux developpeurs wifi sous Linux semblent plebisciter le framework wifi alternatif de Devicescape, qui vient d'être totalement libéré.
Il était question d'intégrer cette pile Deviscape -pour le mieux être de chacun- dans le kernel standard, modulo quelques améliorations dans le code actuel: quelqu'un a des nouvelles ? est-ce toujours d'actualité ?
[^] # Re: Petite question...
Posté par herodiade . En réponse au journal Driver wifi pour OpenBSD. Évalué à 10.
Si tu veut tout savoir sur le support du matériel sur x86, regarde ici:
http://www.openbsd.org/i386.html (et http://www.openbsd.org/macppc.html pour les macs).
Commentaire au sujet du journal: le driver Linux n'utlise pas exactement un « blob opaque qui tourne en espace noyau ». Mais ce driver Linux dépend d'un daemon close source et propriétaire qui tourne en root (et qui cause avec le driver, donc le noyau). Ça, c'était une grande innovation délirante d'Intel, qui avait beaucoup fait jaser, cf. http://kerneltrap.org/node/6270 .
Bref, ce qu'explique Damien Bergamini, c'est que son driver de 3000 lignes fonctionne sans ce daemon propriétaire, qui est nécéssaire au driver Linux (écrit par Intel).
De plus, pour être très précis, on ne peut pas vraiment dire que le driver OpenBSD, pour fonctionner, n'utilise « aucun binaire opaque »: il reste le firmware (binaire, closed source) de la carte à charger à l'intialisation. Mais il est vrai que le firmware ne tourne pas dans le noyau (ni même en userland), il est seulement chargé dans la carte wifi puis exécuté par celle-ci.
La performance de Damien est assez somptueuse, lorsqu'on sait qu'Intel ne lui a pas donné de doc, et qu'il a fait son driver en reverse engeneerant le driver Linux, en trouvant moyen de le réduire au 1/6em en nombre de lignes, de virer la dépendance au daemon root propriétaire, tout ceci en seulement 2 mois après qu'Intel ai publié le driver Linux.
Ce n'est pas le coup d'essai de Damien, il a aussi oeuvré pour les drivers OpenBSD des autres chipsets Wifi Intel, là aussi en reverse engeneerant le driver Linux et en trouvant moyen de le rendre beaucoup plus petit et lisible.
On peut aussi citer son admirable travail pour les chipsets Wifi Ralink (société qui, elle, donne les docs et des firmwares redistribuables): en quelques mois son driver marchait mieux que le driver Linux fournis par Ralink (par comparaison, le projet http://rt2x00.serialmonkey.com de réécriture de ce driver sous Linux patauge depuis presque deux ans sans résultat probant, ce qui montre que ce n'est pas facile).
Sur le lien kerneltrap que je donne ci-dessus, vous pourrez remarquer combien le developpeur kernel Linux Christoph Hellwig a vu juste (et Alan Cox a vu faux), lorsqu'il dit: « If intel doesn't do the right thing support for their hardware will have to wait until someone has reverse-engineered their daemon » !
[^] # Re: Dommage
Posté par herodiade . En réponse à la dépêche Diffusion du film d'animation 3D libre "Elephants Dream". Évalué à 2.
[^] # Re: dommage
Posté par herodiade . En réponse au journal OpenBSD renfloué ?. Évalué à 4.
Celà dit, sortons du troll et revenons aux faits pour parler de cette licence ISC: ce n'est pas inutile, car elle est peu connue.
En fait, Krunch, ce serait plutôt "les deux clauses", seulement.
La licence ISC - préférée par OpenBSD - est identique à la licence BSD « révisée » (que la FSF considère comme l'une des « GPL-Compatible, Free Software Licenses » cf. http://www.fsf.org/licensing/licenses/index_html ) à ceci près que la 3em claus, celle interdisant d'utiliser les noms des auteurs sans consentement écrit, est enlevée, et les 2 clauses restantes sont fusionées en une seule phrase (mais le sens reste identique).
Ça saute aux yeux lorsqu'on les compare en vis à vis:
* La licence ISC :
* La licence BSD révisée :
Donc la seule différence est l'absence, dans la licence ISC, de cette 3em clause qui interdit d'utiliser le nom des auteurs sans permission écrite.
À titre d'info, une des motivations du choix de la licence ISC (de préférence à d'autres licences similaires comme BSD ou Apache) souvent exprimée par les developpeurs d'OpenBSD, c'est qu'ils redoutent les licences avec « too much words », exactement comme ils préfèrent les programmes simples ou avec peu de code, dont ils peuvent en comprendre tout les détails clairement et sans ambiguité (surtout que dans le cas des licences: ils n'ont sans doute pas de conseillés juridiques atitrés sous la main, à la différence peut-être des grosses distros etc.).
Quand à leur position sur la réutilisation du code, elle est bien exprimée - avec tout le langage fleuri qui fait le charme de Theo de Raadt - dans ce commit historique:
http://www.monkey.org/openbsd/archive/source-changes/0105/ms(...)
Julien: si, si, on peut "sub licencer" le logiciel ; la licence prescrit seulement que ce texte doit apparaitre quelque part dans le soft redistribué, mais pas qu'il doit s'appliquer au soft ou que le soft doit etre redistribué sous ces termes.
Ainsi, le site d'OpenBSD précise: « The Berkeley copyright poses no restrictions on private or commercial use of the software and imposes only simple and uniform requirements for maintaining copyright notices in redistributed versions and crediting the originator of the material only in advertising. ». (page http://www.openbsd.org/policy.html ).
C'est pour ça qu'on peut utiliser le code ISC ou BSD rev. pour faire du propriétaire ou du GPL etc.
Et c'est pour ça que la FSF dit « The X11 [MIT] license and the revised BSD license are more or less equivalent. ».
Voir l'explication très claire sur les licences ici:
http://www.openbsd.org/policy.html
Et éventuellement la description des objectifs ici:
http://www.openbsd.org/goals.html
(en particulier, le "goal" suivant: « Integrate good code from any source with acceptable copyright (ISC or Berkeley style preferred, GPL acceptable as a last recourse but not in the kernel, NDA never acceptable). We want to make available source code that anyone can use for ANY PURPOSE, with no restrictions. We strive to make our software robust and secure, and encourage companies to use whichever pieces they want to. »).
Voilou, j'espère avoir clarifié la question des licences BSD rev. et ISC hors de tout troll cette fois ! ;)
[^] # Re: dommage
Posté par herodiade . En réponse au journal OpenBSD renfloué ?. Évalué à 5.
Note que cette licence permet aussi aux programmes GPL de réutiliser le code BSD, ou de se linker sur des libs BSD. C'est au moins aussi courant que la réutilsation de code BSD dans des logiciels proprios, et ça profite à tout le monde.
D'où mon message ci-dessus. Par exemple, leur strlcat.c et strlcpy.c sont récupérés tels quels par plein de trucs, dont PHP, MySQL, Solaris, FreeBSD, Mac OSX, kde-libs, rsync, nmap, dans le noyau Linux, .... Donc le fait que des logiciels propriétaires l'utilisent est un moindre mal par rapport aux bénéfices (et on ne vas pas se priver de tant de bonheur à cause des softs proprios ! ;)
La BSD (ou ISC, qui est en fait maintenant le choix préféré des devs OpenBSD) est compatible avec la GPL, mais la GPL n'est pas compatible avec la BSD (ou ISC, ou MIT, ou CDDL etc.). Sur un plan de compatibilité technique et du partage du code entre utilisateurs de libre: 1 à 0.
[^] # Re: il faut faire quoi ?
Posté par herodiade . En réponse à la dépêche Référentiel Général d'Interopérabilité: Nouvel appel à contributions. Évalué à 8.
Cf. leur effacement de toutes les modifications des règles (avec perte des modifs !) ... un mois après l'ouverture publique du wiki (au lieu d'avoir pris la peine d'expliquer tout de suite aux contributeurs qu'il ne fallait pas modifier directement les règles). Ils ont l'air d'oublier qu'on est arrivé devant un large corpus de règles toutes faites sans avoir la moindre idée des discussions et problématiques qui y ont amené.
Ça n'encourage pas à contribuer, l'impression de travailler dans le vide (ne pas savoir si ce qu'on fait est ne serait-ce que vaguement utile ou complétement à coté de la plaque). D'ailleur j'ai l'impression que beaucoup de débats ont vaguement viré au troll, voir au "choix de la norme obscure mais ayant une implémentation libre" (or l'objectif est l'intéroperabilité, pas le choix politique du libre vs. pas libre) sans que les types qui connaissent les objectifs, la DGME, se donnent la peine de recadrer ou expliquer les orientations, de commenter l' "utilisabilité" ou pas de tel ou tel type de contribution etc.).
# dette
Posté par herodiade . En réponse au journal OpenBSD renfloué ?. Évalué à 10.
On peut donc supposer qu'ils se sont désendétté, mais ce serait vraiment bien qu'il y ai d'autres contribution pour aller au-delà (financer les hackatons, leurs grosses consomation en éléctricité, ou un developpeur à plein temps pendant quelques mois etc.).
Rappelons qu'OpenBSD est un des rares, sinon le seul, OS libres à n'être pas fortement souvenu par des grosses sociétés: FreeBSD et NetBSD sont respectivement largement subventionés (Wasabi etc.), Fedora, Ubuntu et Suse aussi bien sûr, Debian a des developpeurs payés à plein temps par de nombreuses sociétés (Ubuntu, Progeny, Xandros etc.) (et d'une façon générale, les gros fabriquants de chipsets subentionent ou développent souvent eux-même les drivers pour le noyau Linux, ce qui n'est pas le cas pour OpenBSD).
Le travail du projet OpenBSD est utile à tous, même ceux qui n'utilisent pas cet OS. Outre le developpement d'OpenSSH (et autres logiciels portées ailleur comme OpenNTPD, OpenBGPD, OpenOSPFD, ISAKMPD, pf, carp ou systrace), ne pas oublier que:
- Leur audit permanent des logiciels dans le système de base leur permet d'envoyer de nombreux patches de renforcement de la sécurité upstream (apache /mod_ssl, sendmail, tcpdump, perl ...). Un travail d'autant plus utile qu'il est rarement fait par les autres OS (audit et ré-audit du code ligne par ligne, re scan du code à chaque nouveau type de faille ou technique d'attaque découverte ...).
- Ils prennent régulièrement le temps d'écrire des APIs portables qui facilitent la programation sécurisée (strlcat, strlcpy, strtonum, arc4random ...), et/ou de documenter les bonnes pratiques en matière de prog C sécurisée (en tirant parti de leur expérience de 10 ans d'audit).
- Leur engagement pour la liberté du code et des drivers, à coté de la FSF (mais en plus activiste) a souvent porté ses fruits (ouverture des spécifications de matériel, droits de redistribution de firmwares ...).
- Leur experience de pionniers sur certaines technologies de sécurisation permet de faire gagner du temps et éviter des bugs aux autres lorsqu'ils implémentent ultérierement une techno similaire (par ex. leur expérience en crypto avant que les US en autorisent l'exportation, ou l'utilisation de propolice et W^X qui a permis de corriger de nombreux bugs dans les applis userland et donc faciliter l'utilisation de la fonctionalité equivalente dans les distros Linux, leur support des plateformes 64bits en natif (pas d'emulation 32bits sur arch 64bits) qui a aussi levé plein de bugs, ou simplement de démontrer la faisabilité etc...
En somme, et même s'ils sont une "niche" dans l'ecosysteme des OS, leur travail est très bénéfique pour la qualité des distributions GNU/Linux.
Or ils ont encore besoin d'argent, et si vous pouvez les aider, par exemple en achetant un CD ou en faisant un don, ça ne sera pas de l'argent fichu en l'air.
http://www.openbsd.org/donations.html
http://www.openbsd.org/orders.html
[^] # Sécurité des opérateurs ... enforcée par les terminaux clients
Posté par herodiade . En réponse à la dépêche Un téléphone mobile de conception française sous Linux. Évalué à 7.
S'ils comptent réelement là dessus, ils vont avoir, tôt ou tard, des mauvaises surprises (dès que les bidouilleurs s'intéresseront a leurs systèmes). C'est un peu comme si la sécurité de mes serveurs webs était implémentée dans des restrictions de firefox !
Pour revenir au téléphone en question, je ne sait pas vous, mais je le trouve assez light pour un téléphone "high end" "nécéssitant un véritable OS": pas d'UMTS, pas de 3G, pas de Wifi, pas de VoIP, pas de navigateur www, pas de lecteur CF/SD, une autonomie médiocre ... bref, ses caractéristiques ne semblent pas dépasser les traditionels symbian sur nokia d'il y a deux ans. Pas du tout ce que j'attendrai d'un smartphone sous Linux !
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par herodiade . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 2.
En lisant ta réponse j'ai quand même gardé cette question en tête, en pensant (à tord ou à raison ?) que ce genre de « split » (comme LG, mais aussi pour les autres familles) serai une réponse pragmatique :
- Un contournement des bugs et limitations des logiciels dont tu parle (Pango, Qt, et peut-être d'autres ? - si on veut utiliser DejaVu sur d'autres OS, eg. en l'incluant dans un fichier ps, odf ou pdf ? et lorsque les bugs seront corrigés: la rétro-compatibilité avec les vieilles versions bugguées ?). Si j'ai compris ce que tu expliquais, le parti pris actuel semble être assez exigeant, et aurai tendance à butter sur les bugs des libs sous-jacentes (est-ce souhaitable ?)
- Une certaine souplesse pour l'utilisateur dans le choix de ses polices (même sans parler des « styles » comme ci-dessus). Comme DejaVu LG lui permet déjà de choisir la meilleure pour les scripts latins (et une autre pour des scripts différents où DV n'est pas la meilleure), on pourrai imaginer qu'un autre utilisateur souhaiterai utiliser DV pour afficher l'arabe et autre chose pour l'ASCII/latin, et encore autre chose pour ses formules mathématiques. De plus, lorsque la couverture d'une écriture par DV est légèrement incomplète, ce serait peut-être une solution temporaire pour qu'un utilisateur de cette écriture puisse basculer facilement vers un support complet mais moins beau, si cette incomplétude le gène trop ?
- La question du poid et de l'utilisation des ressources (à tout niveaux: poid en mémoire, sur le disque, téléchargements/updates, ...) qui reste effective, surtout si DejaVu est susceptible de progresser très vite et de couvrir de très nombreuses écritures, ou lorsqu'on veut l'utiliser pour de l'embarqué (PDA en Arabe, téléphone en Coréen, OLPC en Afrique ...), ou incluse dans des documents qu'on redistribue.
Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais), un utilisateur arabophone aura le dilemne entre choisir DV LG + une autre police pour l'Arabe, ou DejaVu normal et une grosse utilisation de ressources ; réciproquement pour un utilisateur Japonophone. Une famille de polices façon "DejaVU LG", "DejaVu Arabic", "DejaVu Kanjis", "DejaVu Kanas", ... leur permetrai de choisir les composants qui les intéressse, non ? D'autre part, le calcul du rendu des chaines ne risque-t-il pas d'être ralenti si Pango & co ont besoin de parcourir, à chaque caractère, un grand nombre de glyphes pour trouver celui qu'il doit afficher ?
Est-ce que je me gourre / suis tout à fait à coté de la plaque ?
Et aussi, du coup, si la position des développeurs de DejaVu a été de proposer une version LG réduite aux caractères latins, est-ce que leur position sera aussi de proposer des versions réduites de ce type pour les caractères Arabes etc. ? Quels sont les avantages de distribuer, comme aujoud'hui, tout en un (avec seulement une possibilité de choix pour les caractères de DejaVu LG) ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par herodiade . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 3.
http://bugzilla.gnome.org/show_bug.cgi?id=334758
Notez que les participants au débat (Behdad Esfahbod, Owen Taylor etc.) sont vraiment des core-hackers de gnome ou x.org, et savent de quoi ils parlent.
En bref: ils pense que c'est pas un choix pertinent, qu'il faudrait plutôt spliter DejaVu et la question de poid en mémoire n'est pas le seul problème (cf. l'exemple dans le commentaire #27).
Un exemple de problème intéréssant soulevé par Behdad, c'est que cette approche l'empêche d'utiliser DejaVu pour les scripts latins et choisir simultanément une police rendant correctement les caractères Arabes à la façon Perse (puisque le tout en un DejaVu contraint l'utilisation d'un seul type de glyphe pour un caractère donné).
Une conséquence dommage, c'est que DejaVu était bien présentie pour être la font par defaut de plusieurs distributions, et celles-ci (à ma connaissance, Ubuntu et Fedora) sont en train de revenir d'urgence sur Bitstream, à cause des problèmes induits par l'approche "all in one" (et de certains bugs non corrigés dans DejaVu).
cf. par ex. https://launchpad.net/distros/ubuntu/+source/fontconfig/+bug(...)
Quelle est la position des developpeurs de DejaVu concernant cette question ? envisagent-ils de splitter DejaVu pour les scripts non latins ?
[^] # Re: Et BSD
Posté par herodiade . En réponse à la dépêche Une licence plus permissive pour Java. Évalué à 4.
Par contre il semblerait que l'ouverture dont parle la dépeche, le droit d'intégréer Java dans un OS (de le patcher légèrement, le packager et le redistribuer) ne soit accordé qu'aux distros de Linux et Solaris.
En effet la nouvelle licence http://download.java.net/dlj/DLJ-v1.1.txt dit:
« "Operating System" means any version of the Linux or OpenSolaris operating systems »
Ce qui ne fait pas nos affaires, pour les autres *BSD (et d'autant moins que même Sun ne distribue pas d'implem native pour ces OS).
[^] # Re: Faudrait qu'ils se mettent d'accord
Posté par herodiade . En réponse au journal Java bientot libre ?. Évalué à 5.
Du coup ce mot est utilisé avec des acceptions fort différentes, et c'est bien le problème: certains en profitent pour faire du PR en ventant leur logiciel comme "open source" alors qu'il n'est pas libre.
En l'occurence, c'est exactement ce que Sun a fait dans l'exemple du post auquel je répond: preuve qu'il y a un probleme avec ce terme.
Le terme "logiciel libre" (ou en anglais, pour un maximum de clarté, "free and open source software", ou "free software, in the FSF meaning") n'a pas ce genre d'ambiguité, et ne permet pas de telles jongleries marketing (je n'ai jamais vu un éditeur vanter son logiciel propriétaire en disant qu'il est un "logiciel libre").
C'est ce qu'explique la FSF ici:
http://www.fsf.org/licensing/essays/free-software-for-freedo(...)
[^] # Re: Peut-être un peu bcp de remu ménage pour pas grand chose...
Posté par herodiade . En réponse au journal Java bientot libre ?. Évalué à 3.
Ça donne le droit de redistribuer Java (sous certaines conditions) avec son « Operating System », mais:
So much for the BSD ...
[^] # Re: Faudrait qu'ils se mettent d'accord
Posté par herodiade . En réponse au journal Java bientot libre ?. Évalué à 3.
Leur annonces successives (c'est pas la première) de « nous allons rendre Java Open Source » sont toujours relayées par les journalistes (et même les moules de dlfp ;) alors que c'est un scoop avarié :
- Java est déjà open source (oui, on peut avoir accès aux sources)
- Java n'est pas libre, c'est ça qui pose problème.
Bref, je ne suis pas certain qu'on puisse attendre beaucoup des executives de Sun tant qu'ils continueront à faire cette confusion , opensource / logiciel libre.
Comment peuvent-ils remedier à un problème qu'ils ne comprennent pas bien (ou font semblant de ne pas comprendre) ?
Ils disent vouloir « rendre java opensource tout en empéchant les forks » : je vois mal comment on peut fairer un logiciel libre (librement modifiable, librement redistribuable) avec une telle contrainte. Une idée ?
[^] # Re: petites corrections par rapport au journal
Posté par herodiade . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 7.
Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)
Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.
En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.
D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).
et permet aussi de sortir d'une machine virtuelle Xen.
Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.