Oui, bien entendu. Le but de l'exemple était d'éviter de faire une entrée par utilisateur.
Si on est prêt à faire une entrée dans sshd_config par utilisateur, alors Match User convient aussi bien (dans ce cas, il n'est pas nécessaire que les utilisateurs aient des gid uniques).
> Tu oubli FXP dans l'utilité du canal de contrôle.
Et, à part la dimension tartufesque de ftp (et le risque sécurité bien connu de cette fonctionnalité de ftp, la fameuse "FTP bounce attack"), quel est l'intérêt de FXP par rapport à un simple :
scp user1@server1.com:/truc user2@server2.com:/chose ?
> l'utilisateur se connecte dans le répertoire /var/www/users/son_login mais il apparait comme racine / pour lui.
Non, sftp va se chrooter dans ChrootDir, puis va faire un chdir() dans la home de l'user (telle qu'indiquée dans /etc/passwd, mais relative à la chroot).
Autrement dit, si la home de toto indiquée dans /etc/passwd est "/home/toto", que le ChrootDir indiqué dans sshd_config est est "/chroot", alors sftp :
1- se chrootera dans /chroot
2- puis se déplacera dans /home/toto, relativement à sa chroot (donc en vrai, dans /chroot/home/toto).
3- l'utilisateur toto pourra voir les répertoires contigus à sa home (c'est à dire tout ceux en dessous du répertoire /chroot, y compris /chroot/home/pouet/, s'il existe).
Ce qui me fait penser, au passage et pour compléter la réponse que j'ai donné juste au-dessus, que si on veux garder une arborescence des homes du type /home/user1, /home/user2, alors on doit pouvoir faire :
Match Group sftpusers
ChrootDirectory /home/%u
ForceCommand internal-sftp
Et dans /etc/passwd, indiquer "/" comme path de toutes les homes des utilisateurs qu'on veut chrooter.
> mais je trouve un peu dommage que les autres projets aient enormement moins de publicite en comparaison.
Je me demande si ta remarque est un reproche voilé contre cette dépêche (assimilée à de la « publicité » pour le projet Nouveau) ?
Sinon, même remarque que ci-dessous : si tu estime qu'Intel ne reçoit pas assez de pub, tu peu toujours rédiger une dépêche sur les drivers Intel. Il y a plein de choses à dire, par exemple qu'en ce moment même, la version 2.2.1 de leur pilote est en pre-release (v. 2.2.0.90, déjà très stable, mais à tester d'urgence quand même), qu'il y a du boulot en cours pour améliorer les performances d'EXA sur les i965, que le drm Intel est bien avancé (maintenant, le suspend/resume fonctionne totalement sans recourir à des hacks comme vbetool), ou pour parler de la nouvelle branche pour le refactoring du support XvMC d'Intel (avec en perspective, à la clef, l'accélération de la décompression vidéo), ou pour rendre compte des perspectives des premières expérimentations avec Gallium3d + LLVM ou TTM (expérimentations qui sont d'abord faites, comme le dit cette dépêche, avec un pilote Intel)... Il y a de la matière. Bref, pas assez de pub ? then just do it !
J'en profite au passage pour remercier les rédacteurs de cette dépêche, exceptionnellement claire, solide, passionnante, bien écrite, qui permet de se faire une idée très claire de l'état du pilote, des difficultés rencontrés, des perspectives, et au-delà, de présenter d'excitants outils et méthodes de reverse-engeneering.
Bien sûr, il est dommage qu'Intel ne soit pas mieux récompensé pour avoir ouvert ses specs (et écrit des drivers libres, et embauché des développeurs pour travailler sur l'architecture plus générale, au-delà de leur chapelle). Et on commence à constater qu'ils comptent un peu là-dessus, sur le canal #intel-gfx ou sur la liste de diffusion de xorg, lorsque quelqu'un parle d'une fonctionnalité manquante et qu'ils répondent désormais, en substance, des choses comme : « oui, on aimerai le faire, mais on manque un peu de temps ; les specs sont à votre disposition, vous pouvez nous aider ». (cela dit, ces specs sont ouvertes depuis très peu de temps, et on ne devient pas développeur de pilote X11 du jour au lendemain).
Seulement c'est le temps libre des développeurs bénévoles, pas le mien. S'il n'y a pas assez de monde pour encourager les initiatives d'Intel en développant (ou pas assez de monde pour obtenir une proportion de contributeurs externes quantitativement plus importante pour Intel que pour nvidia), hé bien, ma fois, c'est ainsi, et je vois difficilement comment on pourrait reprocher à d'autres développeurs de participer à d'autres projets.
Si vous voulez qu'il y ai deux fois plus de développeurs externes sur le driver Intel que sur le driver nvidia, vous pouvez vous-même participer, ou embaucher une équipe. Mais reprocher aux bénévoles de ne pas donner de leur temps... (ou, déclinaison du même reproche, reprocher à certains d'être trop nombreux à donner du temps à un autre projet ....), c'est une goujaterie.
En résumé : il ne faut pas dire qu'il y a trop de développeurs Nouveau, mais qu'il n'y a pas assez de développeurs bénévoles Intel ; et on n'est pas moralement en droit d'en faire reproche à qui que ce soit d'autre que soi-même.
Incidemment : vous pouvez aider Intel, même si vous n'êtes pas développeur, en participant à leur programme de test (ils ont lancé un appel à l'aide à ce sujet). Voir la section "Getting Involved" sur : http://www.intellinuxgraphics.org/testing.html
Les développeurs de la libata maintiennent une page très claire et précise sur ce sujet, avec tout les détails intéressants : fonctionnalités supportées, qualité du driver et du matériel, problèmes connus, qualité du design du matériel, est-ce que les spécifications sont publiquement dispos ou pas, etc.
Pas toujours très à jour, mais si votre matériel est indiqué comme "très bien supporté", au moins vous pouvez être assuré qu'il l'est depuis un bon moment. En l'occurrence, pour les deux chipsets SILC SATA, le driver était déjà stable et complet lors de la dernière mise à jour de cette page.
Silicon Image 3124
Driver name: sata_sil24
Summary: Full TCQ/NCQ support, with full SATA control including hotplug and PM.
The 3124 is a nice, open design.
Donc ce chipset semble un très bon choix. En revanche les Silicon Image 3112/3114 supportent moins de fonctionnalités (mais ont tout de même un driver fiable). Encore mieux, si ça t'es possible, opte pour un chipset pouvant fonctionner en mode AHCI (les Southbridge Intel récents ont un excellentissime support d'AHCI).
Ce ne sont pas vraiment mes affirmations, mais, comme j'ai indiqué (et avec des réserves et demandes de confirmations) celles que j'ai trouvé sur le forum indiqué plus haut (que j'ai trop rapidement corroboré avec le fait que mon FF souligne encore les ligatures (mais il s'agit d'un 2.0.11, il faut que je teste la mise à jour)), et sur le site de Vazkor ( http://perso.latribu.com/rocky2/mydico.html où l'on voit qu'il a fait des mises à jour en janvier et indique que la version intégrée dans FF date d'août 2007 ; le README dans les dictionnaires en téléchargement sur votre site parle de septembre 2007).
Comme quoi, une bonne explication détaillée évite bien des confusions (merci de l'avoir fait ici). Peut-être que ces clarifications méritent de figurer dans votre FAQ (parce que c'est bien la première chose que j'ai lu pour essayer de comprendre où allaient les divers forks, qui fait - et a fait - quoi, ce qui était repris ou rejeté parmi les améliorations des autres dictionnaires, et pourquoi, etc.)
Cette mise à jour est une excellente nouvelle, bien entendu. Sans parler du superbe changement de licence (quoiqu'une licence plus permissive, type MIT, aurait permis l'intégration dans d'autres logiciels importants, comme Vim, certains logiciels de messagerie instantanée, etc.).
Mais à fouiller un peu les liens indiqués dans la dépêche et surtout des les commentaires (le lien sur le forum assiste est très instructif : http://assiste.forum.free.fr/viewtopic.php?t=13797 ...), j'en tire une impression de malaise ou pour le moins de relative anarchie. Il semblerait que l'unification des efforts isolés et la prise en compte commune des divers besoins et améliorations subséquentes dans une démarche fédératrice ne soit pas encore à l'ordre du jour.
Pour ce que j'en ai compris - corrigez-moi si je me trompe - ce travail de mise à jour et correction des dicos a été initié par l'énorme travail de Vazkor. Il semblerait qu'ultérieurement, des contributeurs d'OOo (les personnes autour du site Dicollecte / http://dico.savant.free.fr ) aient repris ce travail à un instant donné (dictionnaires de Vazkor, version d'août 2007 - ils ne semblent pas avoir repris ses travaux ultérieurs, bizarrement), l'aient amputé de nombreux apports (enlevé tout les mots avec ligatures (œ, æ) parce que non supporté par OOo sur certaines vieilles plateformes¹, enlevé ses apports intéressants relatifs au filtrage de mots trompeurs comme « détaller » (très rare) vs. « détaler », etc.), mais aient ajouté d'autres apports intéressants (nouveaux mots importants oubliés, quelques corrections, prénoms français, noms des communes de France de plus de 20 000 habitants, ...). Ils ont aussi noyauté les contributeurs aux dictionnaires divers, et proposent une interface intéressante pour soumettre des suggestions. Pour ce que j'en ai compris, c'est leur version qui est intégrée dans les projets OOo (logique) et Mozilla (Vazkor semble trop peut habitué aux mœurs (mot souligné en rouge !) du LL et trop peut anglophone pour défendre sa version, face à celle de Dicollecte, pour l'intégration dans FF).
En conséquence il semblerait qu'on se retrouve avec des scissions, des forks, des versions différentes des dictionnaires. Parfois pour des raisons techniques louables compréhensibles, voir inévitables, mais ça ne clarifie pas les choses. Il semble qu'on ai des dictionnaires français :
- Scindés en versions plus complète (dicos OOo/Dicollecte : prénoms français, grandes villes de France) ou plus correcte (dicos Vazkor : support des ligatures, nombreuses corrections entre août 2007 et février 2008 non reprises par l'équipe OOo/Dicollecte).
- Scindés en versions « orthographe classique » et « orthographe réformée 1990 » (mais Dicollecte fournis une version fusionnée)
- Scindés en versions Myspell et Hunspell.
- Scindés en versions intégrées dans Firefox/TB et versions intégrées dans OOo (visiblement à peut près similaires)
Espérons que ça se tasse avec le temps (probable : unification atour des dicos Hunspell, fusion des dicos classique+réformée, maintenance par l'équipe Dicollecte seule, ...).
Si j'ai bien compris ce qui se passe, je trouve en particulier fort dommage qu'on se tape partout (sans FF, TB et OOo) un dictionnaire ne supportant pas les ligatures² (comment écrivez-vous « œcuménique », « Lætitia », « et cætera » ? Firefox me souligne les mots en rouge et ne propose pas de correction) à cause d'un bug d'OOo sur certaines plateformes. Dommage aussi que le travail de Vazkor entre août 2007 et fin janvier 2008 soit passé à la trappe, et que Vazkor, usé de ce fait, ait décidé d'abandonner son travail³, il était le plus compétent et le plus bosseur (avec Christophe Pythoud, qui a aussi abandonné il y a 8 ans)...
Au rayon des imperfections techniques, il semblerait aussi que les mots composés (avec un trait d'union, quoi) ne soient pas supportés (au moins dans les versions Myspell des dicos) ; l'apostrophes courbe (typographiquement correcte : ´ au lieu de ') non plus. Et la nouvelle licence est bien mieux (permet l'intégration dans OOo, FF et TB) mais ne permet pas l'intégration dans Vim & al.
Ce qui me surprend le plus concernant ces statistiques, c'est le faible écart entre le taux d'utilisation de Linux (environ 3.5 % en 2007) et de Mac OS X (environ 4 %).
J'ai toujours cru que les vendeurs tiers (marchands de matériel, de logiciels, de jeux...) supportaient (mise à disposition des spécifications, écriture de drivers, portage des logiciels) la plateforme d'Apple mais pas Linux parce que ce dernier serait beaucoup moins utilisé, et concernerai donc beaucoup moins de clients. Du moins c'est ce qu'ils disent, en général.
Alors de quatre choses l'une :
1) soit le faible support de Linux est du à un autre problème que les vendeurs tiers préfèrent ne pas indiquer (lequel ? pourquoi ?),
2) soit la différence entre 3.5% et 4% de parts de marché est en fait ultra significative pour eux,
3) soit ces statistiques sur les visiteurs de w3school ne sont pas représentatives des consommateurs en général,
4) soit les vendeurs tiers sont mal informés sur la part de marché réelle de Linux
> pas pour le numéro un, lequel devrait préserver ses secrets pour conserver sa place.
Pour le moment, en termes de nombre de chipsets graphiques vendus, c'est Intel le numéro 1, et de loin (grâce, visiblement, à la proportion des ventes d'ordinateurs portables (chipsets intégrés) en forte hausse par rapport à celle des machines de bureau).
Sur son site Intel cite une étude du marché par Mercury Research selon laquelle les chipsets graphiques Intel représentent à eux seuls 50% des chipsets graphiques vendus :
http://softwarecommunity.intel.com/articles/eng/1485.htm
Une autre étude récente citée ici : http://xtreview.com/translate/fr/?/addcomment-id-1033-view-a(...) donne 40% de parts de marché à Intel (contre, respectivement, 23% et 22% pour ATI et NVIDIA).
C'est donc bel et bien le constructeur numéro 1 qui nous livre ses spécifications, ou encore : de quoi assurer un bon support de Linux sur 50% des machines vendues actuellement :)
D'accord, aucun problème. Pas de nouvelles informations pour le moment, mais je suis sûr que le flot de texte faisant suite à cette annonce révèlera dans les heures qui viennent des choses intéressantes. Faut-il attendre un peu ?
> Les spécifications ne concernant que la dernière puce, assure-toi de prendre du GMA 3000
Ou mieux, une GPU GMA X3x00, avec le X devant (GPU utilisée dans les chipsets G965, G965GM et G35). Les appellations des GPU Intel sont assez difficiles à suivre et trompeuses, c'est pour ça que j'ai indiqué le lien vers la Wikipédia en langue anglaise, qui clarifie les choses : http://en.wikipedia.org/wiki/Intel_GMA . Pour ce que j'en comprends, les chipsets G31, G33 et Q35 utilisent la GPU GMA 3100 (à ne pas confondre avec GMA X3100, et oui !) qui serait seulement une GMA 3000 en moins puissante.
Cela étant, je viens de lire les propos d'un développeur Intel sur irc confirmant que les i915/945 sont très similaires (mais moins fancy faute de vertex shaders et à cause d'un pipeline limitée) et qu'une bonne partie des spécifications restent valables pour ces vieux chipsets.
Au passage, je me suis récemment procuré une carte mère Asus P5E-VM HDMI, intégrant les touts derniers chipsets Intel (northbridge G35, southbridge ICH9R), et c'est un pur bonheur :)
Puisque je vous parle de tests urgents (si vous souhaitez que le pilote dans les prochaines versions de Fedora et Ubuntu soit de bonne qualité), voici comment je m'y prend pour générer un package, sous Ubuntu, à partir de la dernière versions des sources dans ledépôt git des sources du pilote.
Je ne suis pas certain que ce soit la meilleure méthode, mais ça génère un paquet fonctionnel, qu'il est facile d'installer et désinstaller (pour remettre le paquet d'origine fournis par la distribution, trouvez-le dans /var/cache/apt/archives/ et installez-le avec "dpkg -i lepackage.deb"). Pas sûr que ça marche aussi sous Debian (mais les adaptations devraient être mineures).
sudo apt-get build-dep xserver-xorg-video-intel
sudo apt-get install automake autoconf libtool xutils-dev git-core fakeroot
git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
apt-get source xserver-xorg-video-intel
cd xf86-video-intel/
cp -rf ../xserver-xorg-video-intel-*/debian/ .
rm debian/patches/* # on veut tester le git head nu, pas les patchs de sa distro
perl -pi -e 's#usr/share/xserver-xorg/pci/.*##g' debian/*.install
git log > ChangeLog
./autogen.sh
debchange --nmu "git head snapshot"
dpkg-buildpackage -rfakeroot -uc -b
Vous trouverez le paquet ".deb" dans le répertoire parent. N'oubliez pas de tester les choses fragiles, comme le suspend-to-ram, l'hibernation, le switch vers la console (ctrl-alt-f1) et retour, ...
Une méthode équivalente pour générer des paquets pour Fedora serait bienvenue, si quelqu'un connait...
> On peut espérer des progrès du coup dans l'accélération Xvmc
Oui. D'autant plus que les développeurs Intel ont lancé une nouvelle branche git pour un gros remodelage du support xmvc (depuis début janvier je crois).
@patrick_g : c'est très récent. La mise à disposition publique date de cette nuit en fait. Et ça ne sera pas seulement utile pour les autres OS, mais aussi pour ceux qui font des essais de grosses modifications d'xorg, des branches xorg, drm ou mesa expérimentales, ou des frameworks de développement expérimentaux (comme Gallium3D, ou pour améliorer TTM/le modsetting, ou pour jouer avec l'accélération du décode vidéo, pour tester l'implémentation de nouvelles fonctionnalités dans randr, etc, ...). Bref, le fait de disposer à la fois d'un pilote libre de référence et des spécifications complètes permettra aux gens hors Intel/Tungsten Graphics de s'amuser et d'expérimenter plus aisément ;). Ou, plus trivialement, pour ceux qui veulent aider à corriger des bugs.
Ah zut, j'ai raté ton journal, dans la fébrilité de l'annonce, et en ai rédigé un autre. Désolé.
Quoiqu'il en soit, lisez les deux journaux (l'autre apporte des précisions et une autre information concernant un Call for community testers for intel driver) :
>> De son coté ZFS est sous licence CDDL afin précisément de ne pas pouvoir être inclus dans Linux.
> Une source pour confirmer ou c'est juste du vent ?
Oui, finalement, j'ai une source de première main et venant pour ainsi dire de Sun (une ex-employée) indiquant précisément que la CDDL a été construite pour OpenSolaris de façon à être volontairement incompatible avec la GPL.
C'est Denise Cooper (cf. http://en.wikipedia.org/wiki/Danese_Cooper ), « Madame opensource » chez Sun de 1999 à 1995, et qui a notamment participé à la rédaction de la CDDL pour OpenSolaris.
Expliquant pourquoi elle a du baser cette nouvelle licence CDDL sur la Mozilla Public Licence :
Mozilla was selected partially because it is GPL incompatible. That was part of the design when they released OpenSolaris. [...] the engineers who wrote Solaris [...] had some biases about how it should be released, and you have to respect that.
>> Ça ne mange pas de pain. FreeBSD et Mac OS X ne sont franchement des
>> concurents directs pour Sun. Red Hat, IBM et Novell, (c'est à dire Linux), et
>> Microsoft, oui. Eux vendent du support et des garanties pour du gros NAS/SAN
>> et serveurs bado (Oracle & co) Unix.
> Si tu t'étais bien renseigné, sur la page de zfs, on n'y parle pas que du port pour
> FreeBSD et Mac OS X, mais aussi de l'implémentation sous linux (via FUSE).
Quelle mauvaise fois : je citais ces solutions alternatives à Solaris+Zfs pour montrer qu'elles ne font pas d'ombre aux solutions commerciales de Sun. Et tu me parle de Zfs+fuse ?!
Personne ne sera assez fou pour essayer de vendre et supporter des gros serveurs de stockage ou du Oracle utilisant zfs+fuse : ce n'est tout simplement pas compétitif, et tu le sais très bien. Vu les performances (normal pour un fs en userland) et les limitations structurelles (toutes les fonctionalités des systèmes de fichiers ne peuvent pas être implémentés sous fuse), vu, tout simplement, que par nature ces systèmes de fichiers ne sont pas intégrés dans le noyau (donc moindre relecture/audit, etc.), il est clair que zfs-sous-fuse n'est en aucun cas un concurrent pour Sun.
Je passe sur ton « si tu t'étais bien renseigné ». Tu sais que je le sais, et que ça ne fait aucune différence pour ce que j'indiquais (= les implémentations/intégrations alternatives de Zfs ne font pas d'ombre aux produits commerciaux de Sun). L'argument auquel tu répond, et tu le sais aussi très bien, ce n'est pas « impossible de faire du zfs sous linux » mais « impossible de faire du zfs sous linux qui soit commercialement concurrentiel avec Solaris ». N'essaie pas de détourner le sens de mes remarques stp.
> ça aurait été le cas d'un autre projet libre d'utiliser la licence GPLv3 et on n'aurait pas dit ça.
Bah, tout dépend du contexte. Et c'est précisément ce dont on parle. Si tel ou tel composant central d'xorg décide de passer sous GPLv3, on criera au scandale parce que ce choix l'empêcherai *délibérément* d'être intégré dans xorg (sous MIT). À l'inverse, si un composant pour gcc (type Coverty) est libéré sous licence GPLv2-only (ou CDDL) au lieu de GPLv3, on lui fera le même reproche. Pour les logiciels très complexes et difficiles à réimplémenter entièrement, il y a un ecosystème, que personne n'ignore, surtout pas Sun.
Des noyaux d'OS contemporains, il n'y en a pas des dizaines. Et on ne crée pas un nouvel OS sous CDDL ou GPLv3 en claquant des doigts. Alors choisir sa petite licence à soi pour ses fonctionalités sympa, c'est une très bonne façon de faire du libre sans que les autres puissent, en pratique, pleinement profiter de cette liberté.
Comme on dit pour la loi (respect la lettre ou l'esprit de la loi), il y a « respecter la lettre du libre » et « l'esprit du libre ». Utiliser une licence libre qui permet de n'être intégré dans aucun autre noyau concurrent, c'est bien respecter la lettre de la loi mais pas l'esprit de la loi.
>> Sun n'hésite pas à intégrer du code BSD et MIT dans leur noyau (en
>> l'occurence, à repomper des drivers FreeBSD et OpenBSD). Aucun
>> problème légal, donc, pour mettre du code sous une licence compatible
>> GPL dans le noyau Solaris.
> Ben non, mais c'est pas de la faute de Sun. Si des devs distribuent leurs
> outils sous licence BSD ou MIT,
Là encore, tu réponds à coté en me prétant des remarques que je n'ai pas faites. Je n'ai pas fait reproche à Sun d'utiliser du code sous license BSD ou MIT. J'ai dit qu'ils le faisaient, et que ça prouve qu'ils ne sont pas obligés d'utiliser du CDDL pour le code intégré dans leur noyau, et que ça ne pose pas de problème légal.
> Pour le cas des brevets sur ZFS, il ne faut pas sortir l'attaque de SUN du contexte
Peu importe qui a « attaqué le premier ». L'exemple était là pour montrer qu'ils ont des brevets opérationnels. Sun n'a donné de clause d'exploitation des brevets que pour ceux qui utilisent leur implémentation CDDL de Zfs (donc pas de reverse engeneering ni réimplémentation possible, tiens tiens, comme c'est drole).
Maintenant, il faudrait voir à ne pas trop se laisser intoxiquer par le marketing habile et très insistant de Sun (comme pour les fameux « processeurs opensource » - ahaha - ou encore le « java sera bientôt libre » qui traine et devrait sortir à peut près pile poil au moment où les réimplémentation libres alternatives seront 100% compatibles).
Pour le reste : si tu lis les mails des développeurs Linux sur le sujet, tu notera qu'ils considèrent que la situation autour de ces 56 brevets suffit à empêcher pour le moment toute intégration dans le noyau Linux (indépendament de la licence, et même si c'est une réimplémentation from scratch). Ce n'est pas moi qui le dit, ce sont des développeurs du noyau Linux expérimentés.
The real test of whether Sun were serious about ZFS being anywhere but Solaris is what they do to license it - they've patented everything they can, and made the code available only under licenses incompatible with other OS products. Their intent is quite clear, and quite sad.
Theodore Ts'o (développeur ext3/ext4) :
Given that Sun has reportedly filed a huge number of patents covering ZFS and has refused to make them available for anything other than Solaris --- and there are senior Sun programmers who have on record stated that one of the reasons why Sun picked the CDDL was precisely because it was incompatible with GPL and Sun fears Linux ---- I wouldn't bet on Sun being willing to making a patent license available to a hypothetical alternate implementation of the ZFS format for Linux.
Maintenant, comme Linus Torvalds, je ne leur en ferait pas reproche : c'est dans leur intéret, et ça se comprends bien. Mon repproche va plutôt à ceux qui par naïveté relayent un marketing habile mais pas dans l'interet des linuxiens (arrétons le pipotron), ou ceux qui voudraient qu'on adopte une langue de bois sur ces points.
Sachons louer Sun pour ce qu'ils ont vraiment fait, concrètement, de bénéfique pour tout le libre : NFS, par exemple. Ou avoir eu l'intelligence de libérer OpenOffice quand ils ont vu qu'il ne pouvaient en assurer la promotion et la maintenance seuls. Pour avoir finallement libéré Java lorsque les implémentations concurrentes et libres risquaient de devenir le défaut sur tout les serveurs linux. Pour avoir finalement décidé, assez récement, de filer les spécs de tout (ou presque) leur matériel. etc.
> Dans ce cas la, pourquoi feraient-ils de la pub dans le site d'opensolaris pour les projets qui portent ZFS sur les autres OS ?
Simple : parce qu'ils veulent (question d'image de marque) donner une bonne impression dans le monde du F/OSS, et trouvent là, à chaque nouvelle sortie, l'opportunité de maintenir (renouveller !) le buzz médiatique autour de Zfs.
Ça ne mange pas de pain. FreeBSD et Mac OS X ne sont franchement des concurents directs pour Sun. Red Hat, IBM et Novell, (c'est à dire Linux), et Microsoft, oui. Eux vendent du support et des garanties pour du gros NAS/SAN et serveurs bado (Oracle & co) Unix.
Sun a anoncé en 2007 qu'une très grande part de leurs bénéfices venaient de la vente et des services autour de leurs grosses solutions de stockage de masse. D'où la bataille juridique avec NetApp d'ailleurs. Considérer qu'ils auraient « involontairement » empéché l'intégration dans Linux, c'est être soit très naïf, soit de mauvaise foi.
> Le choix de la licence CDDL a peut-être été imposé par le département légal de Sun
Ah ? pourtant :
- J. Schwartz a annoncé qu'ils envisageaient le passage de Zfs à la GPLv3 (bon choix : où comment améliorer l'image libriste tout en restant incompatible avec le noyau linux)
- Sun n'hésite pas à intégrer du code BSD et MIT dans leur noyau (en l'occurence, à repomper des drivers FreeBSD et OpenBSD). Aucun problème légal, donc, pour mettre du code sous une licence compatible GPL dans le noyau Solaris.
>> De son coté ZFS est sous licence CDDL afin précisément de ne pas pouvoir être inclus dans Linux.
> Une source pour confirmer ou c'est juste du vent ?
Pas de sources publiques possibles : Sun (et surtout ses dirigeants) est bien évidement obligé de carresser les amateurs de Linux dans le sens du poil, jouer les amis (il faut voir les nombreux appels du pieds que lance Schwartz, commes les "serveurs gratuits", etc) : de nos jours les jeunes admins et développeurs Unix viennent du monde Linux, ils ne peuvent pas aller contre ça s'ils veulent les séduire. Au pris d'être parfois hypocrite, voir franchement franchement faux cul. Alors ils ne vont évidement pas indiquer publiquement qu'ils ont choisi la CDDL pour bloquer toute inclusion dans Linux.
Enfin (outre le problème volontaire de licence) Sun possède un portefeuil de brevets autour de Zfs (avec lesquels ils ont récement attaqué NetApp), ce qui n'aide pas non plus à l'intégration dans Linux.
> Par propriétaire, j'entendais "propre à (un fournisseur)".
> [...]
> Dans la communauté libriste, le sens est devenu peu à peu synonyme de "non libre".
Bof, non. La communauté du libre aime - avec raison - les standards ouverts, sans brevets connus, normalisés par des instances internationales et indépendantes, disposant de spécifications publiques, et disposant d'implémentations libres.
Mais elle soutient, bien souvent, et pour des raisons pratiques (pas d'alternatives) des standards qui ne répondent pas à toutes ces caractéristiques, et en particulier celle qui te sert à définir de façon très personnelle le « propriétaire ».
En l'occurence : Ogg, Theora et Vorbis sont propres à un seul fournisseur. La dernière fois que j'ai regardé, il n'y avait qu'une seule implémentation, et pas de spécifications ouvertes compltés (au moins, pas pour tout (synchro audio/vidéo par ex), et une implémentation n'est pas une spécification).
Ça a peut-être changé, mais le constat reste le même : qui décide de ce que contiendront et ne contiendront pas les prochaines « implémentations de références » d'Ogg et ses frères ? Xiph, et ses développeurs cooptés.
Même chose pour Dirac, Speex, Tarkin, le format ODF avant d'être normalisé (puis implémenté par ailleurs), la syntaxe des langages python, perl, php, etc. Conclusion : non, tu te trompe, le fait qu'un seul fournisseur décide du format ne fait pas qu'il soit considéré comme propriétaire par la communauté du libre.
Hors sujet : puisqu'on parle de Ogg (le conteneur), je préfère *largement* Matroska. Il est lui aussi libre, dispose d'un overhead beaucoup plus faible (ce qui permet de dégager de la place pour encoder à une meilleure bitrate), et peu encapsuler à peut près n'importe quel format (notamment les sous-titres, où Ogg/Ogm est un peu léger), le chapitrage, les menus, les tags sur les divers contenus, les sous-titres unicodes, ... et a été conçu pour l'audio *et* la vidéo dès le départ (pas le cas de Ogg). Malheureusement, les gens retiennent plutôt le nom de Ogg, poussé et soutenu par une assez grande fondation, et ignorent souvent l'existence de Matroska. Et vous, que pensez-vous de ce conteneur ? avez-vous essayé Matroska ?
[^] # Re: TSO et LRO
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 7.0 et 6.3. Évalué à 6.
Ah, et bien si tu le propose... ça ne serait pas inintéressant de savoir :)
[^] # Re: Plus précisément
Posté par herodiade . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 2.
Si on est prêt à faire une entrée dans sshd_config par utilisateur, alors
Match Userconvient aussi bien (dans ce cas, il n'est pas nécessaire que les utilisateurs aient des gid uniques).[^] # Re: Utilité de FTP ?
Posté par herodiade . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 2.
Et, à part la dimension tartufesque de ftp (et le risque sécurité bien connu de cette fonctionnalité de ftp, la fameuse "FTP bounce attack"), quel est l'intérêt de FXP par rapport à un simple :
scp user1@server1.com:/truc user2@server2.com:/chose ?
[^] # Re: Plus précisément
Posté par herodiade . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 6.
Non, sftp va se chrooter dans ChrootDir, puis va faire un chdir() dans la home de l'user (telle qu'indiquée dans /etc/passwd, mais relative à la chroot).
Autrement dit, si la home de toto indiquée dans /etc/passwd est "/home/toto", que le ChrootDir indiqué dans sshd_config est est "/chroot", alors sftp :
1- se chrootera dans /chroot
2- puis se déplacera dans /home/toto, relativement à sa chroot (donc en vrai, dans /chroot/home/toto).
3- l'utilisateur toto pourra voir les répertoires contigus à sa home (c'est à dire tout ceux en dessous du répertoire /chroot, y compris /chroot/home/pouet/, s'il existe).
Ce qui me fait penser, au passage et pour compléter la réponse que j'ai donné juste au-dessus, que si on veux garder une arborescence des homes du type /home/user1, /home/user2, alors on doit pouvoir faire :
Et dans /etc/passwd, indiquer "/" comme path de toutes les homes des utilisateurs qu'on veut chrooter.
[^] # Re: Plus précisément
Posté par herodiade . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 6.
Non, au login sftp va placer l'utilisateur directement dans /chroot/$HOME/
> Même si les droits sont mis en place pour qu'il ne puisse pas
> rentrer dans les autres répertoires, il les voit.
Voila une astuce simple décrite sur Undeadly, pour éviter que
les utilisateurs ne voient les autres homes :
1) Modifier l'indication des chemins des répertoires home
dans /etc/passwd pour qu'ils ressemblent à : /user1, /user2, ...
2) Créer cette structure de répertoires :
/chroot/user1/user1
/chroot/user2/user2
3) Puis, dans ssh_config :
Et hop, c'est réglé, l'utilisateur ne voit pas les autres homes, seulement la sienne.
[^] # Re: Remplacer ? Pas tout à fait
Posté par herodiade . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 10.
... et plus de vilains bricolages dans les firewall pour laisser passer le traffic FTP DATA en mode actif et en mode passif.
[^] # Re: Polémique
Posté par herodiade . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 6.
Je me demande si ta remarque est un reproche voilé contre cette dépêche (assimilée à de la « publicité » pour le projet Nouveau) ?
Sinon, même remarque que ci-dessous : si tu estime qu'Intel ne reçoit pas assez de pub, tu peu toujours rédiger une dépêche sur les drivers Intel. Il y a plein de choses à dire, par exemple qu'en ce moment même, la version 2.2.1 de leur pilote est en pre-release (v. 2.2.0.90, déjà très stable, mais à tester d'urgence quand même), qu'il y a du boulot en cours pour améliorer les performances d'EXA sur les i965, que le drm Intel est bien avancé (maintenant, le suspend/resume fonctionne totalement sans recourir à des hacks comme vbetool), ou pour parler de la nouvelle branche pour le refactoring du support XvMC d'Intel (avec en perspective, à la clef, l'accélération de la décompression vidéo), ou pour rendre compte des perspectives des premières expérimentations avec Gallium3d + LLVM ou TTM (expérimentations qui sont d'abord faites, comme le dit cette dépêche, avec un pilote Intel)... Il y a de la matière. Bref, pas assez de pub ? then just do it !
J'en profite au passage pour remercier les rédacteurs de cette dépêche, exceptionnellement claire, solide, passionnante, bien écrite, qui permet de se faire une idée très claire de l'état du pilote, des difficultés rencontrés, des perspectives, et au-delà, de présenter d'excitants outils et méthodes de reverse-engeneering.
[^] # Re: Polémique
Posté par herodiade . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 8.
Seulement c'est le temps libre des développeurs bénévoles, pas le mien. S'il n'y a pas assez de monde pour encourager les initiatives d'Intel en développant (ou pas assez de monde pour obtenir une proportion de contributeurs externes quantitativement plus importante pour Intel que pour nvidia), hé bien, ma fois, c'est ainsi, et je vois difficilement comment on pourrait reprocher à d'autres développeurs de participer à d'autres projets.
Si vous voulez qu'il y ai deux fois plus de développeurs externes sur le driver Intel que sur le driver nvidia, vous pouvez vous-même participer, ou embaucher une équipe. Mais reprocher aux bénévoles de ne pas donner de leur temps... (ou, déclinaison du même reproche, reprocher à certains d'être trop nombreux à donner du temps à un autre projet ....), c'est une goujaterie.
En résumé : il ne faut pas dire qu'il y a trop de développeurs Nouveau, mais qu'il n'y a pas assez de développeurs bénévoles Intel ; et on n'est pas moralement en droit d'en faire reproche à qui que ce soit d'autre que soi-même.
Incidemment : vous pouvez aider Intel, même si vous n'êtes pas développeur, en participant à leur programme de test (ils ont lancé un appel à l'aide à ce sujet). Voir la section "Getting Involved" sur :
http://www.intellinuxgraphics.org/testing.html
# La page de référence pour avoir ces renseignements
Posté par herodiade . En réponse au journal Carte contrôleur sATA pour carte mère ancienne génération (PCIà. Évalué à 8.
Pas toujours très à jour, mais si votre matériel est indiqué comme "très bien supporté", au moins vous pouvez être assuré qu'il l'est depuis un bon moment. En l'occurrence, pour les deux chipsets SILC SATA, le driver était déjà stable et complet lors de la dernière mise à jour de cette page.
Silicon Image 3124
Driver name: sata_sil24
Summary: Full TCQ/NCQ support, with full SATA control including hotplug and PM.
The 3124 is a nice, open design.
Donc ce chipset semble un très bon choix. En revanche les Silicon Image 3112/3114 supportent moins de fonctionnalités (mais ont tout de même un driver fiable). Encore mieux, si ça t'es possible, opte pour un chipset pouvant fonctionner en mode AHCI (les Southbridge Intel récents ont un excellentissime support d'AHCI).
La page en question : http://linux-ata.org/driver-status.html
[^] # Re: Ligatures.. et scissions
Posté par herodiade . En réponse à la dépêche Dictionnaire orthographique français inclus par défaut dans Firefox, Thunderbird et Seamonkey. Évalué à 4.
Ce ne sont pas vraiment mes affirmations, mais, comme j'ai indiqué (et avec des réserves et demandes de confirmations) celles que j'ai trouvé sur le forum indiqué plus haut (que j'ai trop rapidement corroboré avec le fait que mon FF souligne encore les ligatures (mais il s'agit d'un 2.0.11, il faut que je teste la mise à jour)), et sur le site de Vazkor ( http://perso.latribu.com/rocky2/mydico.html où l'on voit qu'il a fait des mises à jour en janvier et indique que la version intégrée dans FF date d'août 2007 ; le README dans les dictionnaires en téléchargement sur votre site parle de septembre 2007).
Comme quoi, une bonne explication détaillée évite bien des confusions (merci de l'avoir fait ici). Peut-être que ces clarifications méritent de figurer dans votre FAQ (parce que c'est bien la première chose que j'ai lu pour essayer de comprendre où allaient les divers forks, qui fait - et a fait - quoi, ce qui était repris ou rejeté parmi les améliorations des autres dictionnaires, et pourquoi, etc.)
# Ligatures.. et scissions
Posté par herodiade . En réponse à la dépêche Dictionnaire orthographique français inclus par défaut dans Firefox, Thunderbird et Seamonkey. Évalué à 6.
Mais à fouiller un peu les liens indiqués dans la dépêche et surtout des les commentaires (le lien sur le forum assiste est très instructif : http://assiste.forum.free.fr/viewtopic.php?t=13797 ...), j'en tire une impression de malaise ou pour le moins de relative anarchie. Il semblerait que l'unification des efforts isolés et la prise en compte commune des divers besoins et améliorations subséquentes dans une démarche fédératrice ne soit pas encore à l'ordre du jour.
Pour ce que j'en ai compris - corrigez-moi si je me trompe - ce travail de mise à jour et correction des dicos a été initié par l'énorme travail de Vazkor. Il semblerait qu'ultérieurement, des contributeurs d'OOo (les personnes autour du site Dicollecte / http://dico.savant.free.fr ) aient repris ce travail à un instant donné (dictionnaires de Vazkor, version d'août 2007 - ils ne semblent pas avoir repris ses travaux ultérieurs, bizarrement), l'aient amputé de nombreux apports (enlevé tout les mots avec ligatures (œ, æ) parce que non supporté par OOo sur certaines vieilles plateformes¹, enlevé ses apports intéressants relatifs au filtrage de mots trompeurs comme « détaller » (très rare) vs. « détaler », etc.), mais aient ajouté d'autres apports intéressants (nouveaux mots importants oubliés, quelques corrections, prénoms français, noms des communes de France de plus de 20 000 habitants, ...). Ils ont aussi noyauté les contributeurs aux dictionnaires divers, et proposent une interface intéressante pour soumettre des suggestions. Pour ce que j'en ai compris, c'est leur version qui est intégrée dans les projets OOo (logique) et Mozilla (Vazkor semble trop peut habitué aux mœurs (mot souligné en rouge !) du LL et trop peut anglophone pour défendre sa version, face à celle de Dicollecte, pour l'intégration dans FF).
En conséquence il semblerait qu'on se retrouve avec des scissions, des forks, des versions différentes des dictionnaires. Parfois pour des raisons techniques louables compréhensibles, voir inévitables, mais ça ne clarifie pas les choses. Il semble qu'on ai des dictionnaires français :
- Scindés en versions plus complète (dicos OOo/Dicollecte : prénoms français, grandes villes de France) ou plus correcte (dicos Vazkor : support des ligatures, nombreuses corrections entre août 2007 et février 2008 non reprises par l'équipe OOo/Dicollecte).
- Scindés en versions « orthographe classique » et « orthographe réformée 1990 » (mais Dicollecte fournis une version fusionnée)
- Scindés en versions Myspell et Hunspell.
- Scindés en versions intégrées dans Firefox/TB et versions intégrées dans OOo (visiblement à peut près similaires)
Espérons que ça se tasse avec le temps (probable : unification atour des dicos Hunspell, fusion des dicos classique+réformée, maintenance par l'équipe Dicollecte seule, ...).
Si j'ai bien compris ce qui se passe, je trouve en particulier fort dommage qu'on se tape partout (sans FF, TB et OOo) un dictionnaire ne supportant pas les ligatures² (comment écrivez-vous « œcuménique », « Lætitia », « et cætera » ? Firefox me souligne les mots en rouge et ne propose pas de correction) à cause d'un bug d'OOo sur certaines plateformes. Dommage aussi que le travail de Vazkor entre août 2007 et fin janvier 2008 soit passé à la trappe, et que Vazkor, usé de ce fait, ait décidé d'abandonner son travail³, il était le plus compétent et le plus bosseur (avec Christophe Pythoud, qui a aussi abandonné il y a 8 ans)...
Au rayon des imperfections techniques, il semblerait aussi que les mots composés (avec un trait d'union, quoi) ne soient pas supportés (au moins dans les versions Myspell des dicos) ; l'apostrophes courbe (typographiquement correcte : ´ au lieu de ') non plus. Et la nouvelle licence est bien mieux (permet l'intégration dans OOo, FF et TB) mais ne permet pas l'intégration dans Vim & al.
¹ Du moins, c'est ce qui est expliqué en bas de cette page : http://assiste.forum.free.fr/viewtopic.php?t=13797&postd(...) . Est-ce co
rrect ? Ou s'agit-il d'un bug de Myspell et d'Hunspell ? Pourtant Vazkor semble avoir réussi à produire un dico avec ligature qui fonctionne sous FF et OOo : http://assiste.forum.free.fr/viewtopic.php?p=107681#107681
² Cf. par exemple ici la motivation du rejet du mot « nœthérienne » : http://dico.savant.free.fr/proposition.php?id=513
³ Voir par exemple son annonce sur son site : http://perso.latribu.com/rocky2/mydico.html . Il continue néanmoins son excellent travail de correction des art
icles de Wikipédia (cf. http://fr.wikipedia.org/wiki/Special:Contributions/Vazkor ).
Voila. Si quelqu'un en sait un peu plus sur les problèmes évoqués et les possibilités de résolution, ce serait chouette de nous en parler.
[^] # Re: Complément
Posté par herodiade . En réponse au journal Ubuntu, Vim et Bash. Évalué à 6.
> http://www.w3schools.com/browsers/browsers_os.asp
Ce qui me surprend le plus concernant ces statistiques, c'est le faible écart entre le taux d'utilisation de Linux (environ 3.5 % en 2007) et de Mac OS X (environ 4 %).
J'ai toujours cru que les vendeurs tiers (marchands de matériel, de logiciels, de jeux...) supportaient (mise à disposition des spécifications, écriture de drivers, portage des logiciels) la plateforme d'Apple mais pas Linux parce que ce dernier serait beaucoup moins utilisé, et concernerai donc beaucoup moins de clients. Du moins c'est ce qu'ils disent, en général.
Alors de quatre choses l'une :
1) soit le faible support de Linux est du à un autre problème que les vendeurs tiers préfèrent ne pas indiquer (lequel ? pourquoi ?),
2) soit la différence entre 3.5% et 4% de parts de marché est en fait ultra significative pour eux,
3) soit ces statistiques sur les visiteurs de w3school ne sont pas représentatives des consommateurs en général,
4) soit les vendeurs tiers sont mal informés sur la part de marché réelle de Linux
[^] # Re: Incroyable
Posté par herodiade . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 3.
[^] # Re: My bad
Posté par herodiade . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 4.
[^] # Re: Intel livre les spécifications complètes de ses chipsets graphique
Posté par herodiade . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 7.
Ou mieux, une GPU GMA X3x00, avec le X devant (GPU utilisée dans les chipsets G965, G965GM et G35). Les appellations des GPU Intel sont assez difficiles à suivre et trompeuses, c'est pour ça que j'ai indiqué le lien vers la Wikipédia en langue anglaise, qui clarifie les choses : http://en.wikipedia.org/wiki/Intel_GMA . Pour ce que j'en comprends, les chipsets G31, G33 et Q35 utilisent la GPU GMA 3100 (à ne pas confondre avec GMA X3100, et oui !) qui serait seulement une GMA 3000 en moins puissante.
Cela étant, je viens de lire les propos d'un développeur Intel sur irc confirmant que les i915/945 sont très similaires (mais moins fancy faute de vertex shaders et à cause d'un pipeline limitée) et qu'une bonne partie des spécifications restent valables pour ces vieux chipsets.
Au passage, je me suis récemment procuré une carte mère Asus P5E-VM HDMI, intégrant les touts derniers chipsets Intel (northbridge G35, southbridge ICH9R), et c'est un pur bonheur :)
# Tester le dernier pilote sous Ubuntu ou Debian
Posté par herodiade . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 10.
Je ne suis pas certain que ce soit la meilleure méthode, mais ça génère un paquet fonctionnel, qu'il est facile d'installer et désinstaller (pour remettre le paquet d'origine fournis par la distribution, trouvez-le dans /var/cache/apt/archives/ et installez-le avec "dpkg -i lepackage.deb"). Pas sûr que ça marche aussi sous Debian (mais les adaptations devraient être mineures).
sudo apt-get build-dep xserver-xorg-video-intel
sudo apt-get install automake autoconf libtool xutils-dev git-core fakeroot
git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
apt-get source xserver-xorg-video-intel
cd xf86-video-intel/
cp -rf ../xserver-xorg-video-intel-*/debian/ .
rm debian/patches/* # on veut tester le git head nu, pas les patchs de sa distro
perl -pi -e 's#usr/share/xserver-xorg/pci/.*##g' debian/*.install
git log > ChangeLog
./autogen.sh
debchange --nmu "git head snapshot"
dpkg-buildpackage -rfakeroot -uc -b
Vous trouverez le paquet ".deb" dans le répertoire parent. N'oubliez pas de tester les choses fragiles, comme le suspend-to-ram, l'hibernation, le switch vers la console (ctrl-alt-f1) et retour, ...
Une méthode équivalente pour générer des paquets pour Fedora serait bienvenue, si quelqu'un connait...
[^] # Re: Intel et le libre
Posté par herodiade . En réponse au journal Intel publie plus de 1600 pages de documentation. Évalué à 5.
Oui. D'autant plus que les développeurs Intel ont lancé une nouvelle branche git pour un gros remodelage du support xmvc (depuis début janvier je crois).
@patrick_g : c'est très récent. La mise à disposition publique date de cette nuit en fait. Et ça ne sera pas seulement utile pour les autres OS, mais aussi pour ceux qui font des essais de grosses modifications d'xorg, des branches xorg, drm ou mesa expérimentales, ou des frameworks de développement expérimentaux (comme Gallium3D, ou pour améliorer TTM/le modsetting, ou pour jouer avec l'accélération du décode vidéo, pour tester l'implémentation de nouvelles fonctionnalités dans randr, etc, ...). Bref, le fait de disposer à la fois d'un pilote libre de référence et des spécifications complètes permettra aux gens hors Intel/Tungsten Graphics de s'amuser et d'expérimenter plus aisément ;). Ou, plus trivialement, pour ceux qui veulent aider à corriger des bugs.
# My bad
Posté par herodiade . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 10.
http://linuxfr.org/~IsNotGood/26078.html
Bon, on va prétendre que ce n'est pas vraiment un doublon puisque j'y parle aussi du Call for community testers for intel driver ;)
# Autre journal en doublons, désolé
Posté par herodiade . En réponse au journal Intel publie plus de 1600 pages de documentation. Évalué à 2.
Quoiqu'il en soit, lisez les deux journaux (l'autre apporte des précisions et une autre information concernant un Call for community testers for intel driver) :
http://linuxfr.org/~herodiade/26080.html
[^] # Re: ZFS ?
Posté par herodiade . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 4.
> Une source pour confirmer ou c'est juste du vent ?
Oui, finalement, j'ai une source de première main et venant pour ainsi dire de Sun (une ex-employée) indiquant précisément que la CDDL a été construite pour OpenSolaris de façon à être volontairement incompatible avec la GPL.
C'est Denise Cooper (cf. http://en.wikipedia.org/wiki/Danese_Cooper ), « Madame opensource » chez Sun de 1999 à 1995, et qui a notamment participé à la rédaction de la CDDL pour OpenSolaris.
Expliquant pourquoi elle a du baser cette nouvelle licence CDDL sur la Mozilla Public Licence :
Source :
http://meetings-archive.debian.net/pub/debian-meetings/2006/(...)
[^] # Re: ZFS ?
Posté par herodiade . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 5.
>> concurents directs pour Sun. Red Hat, IBM et Novell, (c'est à dire Linux), et
>> Microsoft, oui. Eux vendent du support et des garanties pour du gros NAS/SAN
>> et serveurs bado (Oracle & co) Unix.
> Si tu t'étais bien renseigné, sur la page de zfs, on n'y parle pas que du port pour
> FreeBSD et Mac OS X, mais aussi de l'implémentation sous linux (via FUSE).
Quelle mauvaise fois : je citais ces solutions alternatives à Solaris+Zfs pour montrer qu'elles ne font pas d'ombre aux solutions commerciales de Sun. Et tu me parle de Zfs+fuse ?!
Personne ne sera assez fou pour essayer de vendre et supporter des gros serveurs de stockage ou du Oracle utilisant zfs+fuse : ce n'est tout simplement pas compétitif, et tu le sais très bien. Vu les performances (normal pour un fs en userland) et les limitations structurelles (toutes les fonctionalités des systèmes de fichiers ne peuvent pas être implémentés sous fuse), vu, tout simplement, que par nature ces systèmes de fichiers ne sont pas intégrés dans le noyau (donc moindre relecture/audit, etc.), il est clair que zfs-sous-fuse n'est en aucun cas un concurrent pour Sun.
Je passe sur ton « si tu t'étais bien renseigné ». Tu sais que je le sais, et que ça ne fait aucune différence pour ce que j'indiquais (= les implémentations/intégrations alternatives de Zfs ne font pas d'ombre aux produits commerciaux de Sun). L'argument auquel tu répond, et tu le sais aussi très bien, ce n'est pas « impossible de faire du zfs sous linux » mais « impossible de faire du zfs sous linux qui soit commercialement concurrentiel avec Solaris ». N'essaie pas de détourner le sens de mes remarques stp.
> ça aurait été le cas d'un autre projet libre d'utiliser la licence GPLv3 et on n'aurait pas dit ça.
Bah, tout dépend du contexte. Et c'est précisément ce dont on parle. Si tel ou tel composant central d'xorg décide de passer sous GPLv3, on criera au scandale parce que ce choix l'empêcherai *délibérément* d'être intégré dans xorg (sous MIT). À l'inverse, si un composant pour gcc (type Coverty) est libéré sous licence GPLv2-only (ou CDDL) au lieu de GPLv3, on lui fera le même reproche. Pour les logiciels très complexes et difficiles à réimplémenter entièrement, il y a un ecosystème, que personne n'ignore, surtout pas Sun.
Des noyaux d'OS contemporains, il n'y en a pas des dizaines. Et on ne crée pas un nouvel OS sous CDDL ou GPLv3 en claquant des doigts. Alors choisir sa petite licence à soi pour ses fonctionalités sympa, c'est une très bonne façon de faire du libre sans que les autres puissent, en pratique, pleinement profiter de cette liberté.
Comme on dit pour la loi (respect la lettre ou l'esprit de la loi), il y a « respecter la lettre du libre » et « l'esprit du libre ». Utiliser une licence libre qui permet de n'être intégré dans aucun autre noyau concurrent, c'est bien respecter la lettre de la loi mais pas l'esprit de la loi.
>> Sun n'hésite pas à intégrer du code BSD et MIT dans leur noyau (en
>> l'occurence, à repomper des drivers FreeBSD et OpenBSD). Aucun
>> problème légal, donc, pour mettre du code sous une licence compatible
>> GPL dans le noyau Solaris.
> Ben non, mais c'est pas de la faute de Sun. Si des devs distribuent leurs
> outils sous licence BSD ou MIT,
Là encore, tu réponds à coté en me prétant des remarques que je n'ai pas faites. Je n'ai pas fait reproche à Sun d'utiliser du code sous license BSD ou MIT. J'ai dit qu'ils le faisaient, et que ça prouve qu'ils ne sont pas obligés d'utiliser du CDDL pour le code intégré dans leur noyau, et que ça ne pose pas de problème légal.
[^] # Re: ZFS ?
Posté par herodiade . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 2.
Peu importe qui a « attaqué le premier ». L'exemple était là pour montrer qu'ils ont des brevets opérationnels. Sun n'a donné de clause d'exploitation des brevets que pour ceux qui utilisent leur implémentation CDDL de Zfs (donc pas de reverse engeneering ni réimplémentation possible, tiens tiens, comme c'est drole).
Maintenant, il faudrait voir à ne pas trop se laisser intoxiquer par le marketing habile et très insistant de Sun (comme pour les fameux « processeurs opensource » - ahaha - ou encore le « java sera bientôt libre » qui traine et devrait sortir à peut près pile poil au moment où les réimplémentation libres alternatives seront 100% compatibles).
Pour le reste : si tu lis les mails des développeurs Linux sur le sujet, tu notera qu'ils considèrent que la situation autour de ces 56 brevets suffit à empêcher pour le moment toute intégration dans le noyau Linux (indépendament de la licence, et même si c'est une réimplémentation from scratch). Ce n'est pas moi qui le dit, ce sont des développeurs du noyau Linux expérimentés.
Ou, pour citer directement les personnes concernées (source : http://kerneltrap.org/node/8066 ):
Alan Cox :
Theodore Ts'o (développeur ext3/ext4) :
Maintenant, comme Linus Torvalds, je ne leur en ferait pas reproche : c'est dans leur intéret, et ça se comprends bien. Mon repproche va plutôt à ceux qui par naïveté relayent un marketing habile mais pas dans l'interet des linuxiens (arrétons le pipotron), ou ceux qui voudraient qu'on adopte une langue de bois sur ces points.
Sachons louer Sun pour ce qu'ils ont vraiment fait, concrètement, de bénéfique pour tout le libre : NFS, par exemple. Ou avoir eu l'intelligence de libérer OpenOffice quand ils ont vu qu'il ne pouvaient en assurer la promotion et la maintenance seuls. Pour avoir finallement libéré Java lorsque les implémentations concurrentes et libres risquaient de devenir le défaut sur tout les serveurs linux. Pour avoir finalement décidé, assez récement, de filer les spécs de tout (ou presque) leur matériel. etc.
[^] # Re: ZFS ?
Posté par herodiade . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 1.
Simple : parce qu'ils veulent (question d'image de marque) donner une bonne impression dans le monde du F/OSS, et trouvent là, à chaque nouvelle sortie, l'opportunité de maintenir (renouveller !) le buzz médiatique autour de Zfs.
Ça ne mange pas de pain. FreeBSD et Mac OS X ne sont franchement des concurents directs pour Sun. Red Hat, IBM et Novell, (c'est à dire Linux), et Microsoft, oui. Eux vendent du support et des garanties pour du gros NAS/SAN et serveurs bado (Oracle & co) Unix.
Sun a anoncé en 2007 qu'une très grande part de leurs bénéfices venaient de la vente et des services autour de leurs grosses solutions de stockage de masse. D'où la bataille juridique avec NetApp d'ailleurs. Considérer qu'ils auraient « involontairement » empéché l'intégration dans Linux, c'est être soit très naïf, soit de mauvaise foi.
> Le choix de la licence CDDL a peut-être été imposé par le département légal de Sun
Ah ? pourtant :
- J. Schwartz a annoncé qu'ils envisageaient le passage de Zfs à la GPLv3 (bon choix : où comment améliorer l'image libriste tout en restant incompatible avec le noyau linux)
- Sun n'hésite pas à intégrer du code BSD et MIT dans leur noyau (en l'occurence, à repomper des drivers FreeBSD et OpenBSD). Aucun problème légal, donc, pour mettre du code sous une licence compatible GPL dans le noyau Solaris.
[^] # Re: ZFS ?
Posté par herodiade . En réponse à la dépêche Btrfs : Le système de fichiers du futur. Évalué à 3.
> Une source pour confirmer ou c'est juste du vent ?
Pas de sources publiques possibles : Sun (et surtout ses dirigeants) est bien évidement obligé de carresser les amateurs de Linux dans le sens du poil, jouer les amis (il faut voir les nombreux appels du pieds que lance Schwartz, commes les "serveurs gratuits", etc) : de nos jours les jeunes admins et développeurs Unix viennent du monde Linux, ils ne peuvent pas aller contre ça s'ils veulent les séduire. Au pris d'être parfois hypocrite, voir franchement franchement faux cul. Alors ils ne vont évidement pas indiquer publiquement qu'ils ont choisi la CDDL pour bloquer toute inclusion dans Linux.
Pas de sources publiques possibles, donc, mais les analyses des gens informés dans le domaine convergent toutes pour confirmer que Sun a fait ce choix d'incompatibilité (pour Dtrace et Zfs) volontairement. Par exemple, les analyses de :
Theodore Tso : http://lkml.org/lkml/2007/4/17/285
Alan Cox : http://lkml.org/lkml/2007/4/17/202
Linus Torvalds : http://lkml.org/lkml/2007/6/12/232
Enfin (outre le problème volontaire de licence) Sun possède un portefeuil de brevets autour de Zfs (avec lesquels ils ont récement attaqué NetApp), ce qui n'aide pas non plus à l'intégration dans Linux.
[^] # Re: Est-ce vraiment la voie à suivre ?
Posté par herodiade . En réponse au journal Wikipedia met l'Ogg sur le devant de la scène. Évalué à 3.
> [...]
> Dans la communauté libriste, le sens est devenu peu à peu synonyme de "non libre".
Bof, non. La communauté du libre aime - avec raison - les standards ouverts, sans brevets connus, normalisés par des instances internationales et indépendantes, disposant de spécifications publiques, et disposant d'implémentations libres.
Mais elle soutient, bien souvent, et pour des raisons pratiques (pas d'alternatives) des standards qui ne répondent pas à toutes ces caractéristiques, et en particulier celle qui te sert à définir de façon très personnelle le « propriétaire ».
En l'occurence : Ogg, Theora et Vorbis sont propres à un seul fournisseur. La dernière fois que j'ai regardé, il n'y avait qu'une seule implémentation, et pas de spécifications ouvertes compltés (au moins, pas pour tout (synchro audio/vidéo par ex), et une implémentation n'est pas une spécification).
Ça a peut-être changé, mais le constat reste le même : qui décide de ce que contiendront et ne contiendront pas les prochaines « implémentations de références » d'Ogg et ses frères ? Xiph, et ses développeurs cooptés.
Même chose pour Dirac, Speex, Tarkin, le format ODF avant d'être normalisé (puis implémenté par ailleurs), la syntaxe des langages python, perl, php, etc. Conclusion : non, tu te trompe, le fait qu'un seul fournisseur décide du format ne fait pas qu'il soit considéré comme propriétaire par la communauté du libre.
Hors sujet : puisqu'on parle de Ogg (le conteneur), je préfère *largement* Matroska. Il est lui aussi libre, dispose d'un overhead beaucoup plus faible (ce qui permet de dégager de la place pour encoder à une meilleure bitrate), et peu encapsuler à peut près n'importe quel format (notamment les sous-titres, où Ogg/Ogm est un peu léger), le chapitrage, les menus, les tags sur les divers contenus, les sous-titres unicodes, ... et a été conçu pour l'audio *et* la vidéo dès le départ (pas le cas de Ogg). Malheureusement, les gens retiennent plutôt le nom de Ogg, poussé et soutenu par une assez grande fondation, et ignorent souvent l'existence de Matroska. Et vous, que pensez-vous de ce conteneur ? avez-vous essayé Matroska ?
http://www.alexander-noe.com/video/documentation/containers.(...)