zul a écrit 443 commentaires

Ils travaillent dessus : ils font des snapshots plus ou moins régulier du code de NetBSD :). Le code de drm est de toute façon relativement portable, donc c'est envisageable. M'enfin, par default et que ca marche c'est pas évident, même si ils ont M. Herbb avec eux. Dri marchotte sur certaines cartes NetBSD, mais bon c'est pas encore super opérationnel.

Concernant MPLS, ce n'est qu'une intégration du projet AYAME. Pas la peine de crier au génie. Par contre, on peut remercier le projet AYAME pour son taff. Quelqu'un est aussi en train de l'intégrer dans NetBSD depuis un bon moment, mais je ne saurai dire si ca sera prêt pour 5.0.

Sinon excellent travail de Damien sur WPA, même si je considère qu'ils auraient mieux fait de contribuer à la pile commune FreeBSD/NetBSD/DragonflyBSD qui supporte le WPA depuis bien des années maintenant (et d'autres choses sexy dans FreeBSD).

Cette réponse prouve bien que
1/ tu as marché dedans bien profond
2/ que les utilisateurs d'OpenBSD sont des psychorigides incapables de comprendre l'humour (pour bien continuer :D)
3/ c'est malheuresement vrai. Sans parler d'un site russe avec des cds plein de backdoor, j'ai vu à plusieurs reprises de gens téléchargés sur des isos non officiels faites par des personnes quelconques (comprendre n'ayant rien pour assurer une confiance).

FYI, le support des VAP ont été commité dans FreeBSD le 20 Avril. Ça faisait bien 3 ans qu'ils nous en parlaient, ils l'ont fait (et pas que pour ath, le support est bien évidemment à 90% dans net80211).

Le code sera sous GPL (99% de chance, je suis un peu prophète sur les bords). Il ne pourra pas être réutilisé dans un BSD (à par en le réécrivant).

Quand à la possibilité de fournir une documentation, on peut rêver je pense (prophète mode 2). De plus en plus de constructeurs fournissent des drivers linux libres, mais sans aucune documentation (on peut penser aux drivers Intel par exemple). Il nous faut donc rétro engineerer le code source Linux en faisant fort attention à ne pas reprendre une seule demi ligne de GPL sinon attention. C'est un peu plus simple que de partir du binaire bien-sûr mais ça reste globalement pas la joie, surtout qu'on a évidemment aucun moyen de maintenir sérieusement le code (le code GPL est maintenu par la société éditrice, quid happen si ils ne veulent plus le maintenir pour leur vieille carte ?), aucun moyen de voir les possibles bugs introduits dans le driver linux, etc ... Je ne sais donc pas si il faut trop se réjouir de ce "nouveau driver libre".

Le plus simple serait probablement de juste releaser le code source du HAL sous une licence permissive, afin de pouvoir réutiliser le travail de madwifi, travail admirable fait depuis des années par des développeurs BSD et Linux.

Si une boite propriétaire fait un produit à partir d'un logiciel BSD, est que ca te prive de la liberté d'avoir el code et d'utiliser ledit logiciel BSD ? Je ne crois pas (j'en suis même sur).

De plus, je note que contrairement à ce que tu pense, beaucoup de choses sont reversés directement ou indirectement à ces projets BSD (Juniper pour FreeBSD; Wasabi/QNX pour NetBSD (tips : grosse contribution de Wasabi bientot dans NetBSD juste pour te faire mentir)).

Si Mme Michu préfère un logiciel propriétaire équivalent à un logiciel libre (à 2micro fonctionnalités près), c'est son droit. Je ne vois pas pourquoi tu compte lui interdire. Toi qui te soucie de ta liberté, tu peux toujours utiliser le loiciel libre.

Fait un fork GPL d'un logiciel BSD, c'est très pertinent, comme ça tu es sur que le logiciel BSD pourra pas reprendre tes modifs. C'est beau comme contribution :).

Linus est pragmatique. Il s'en fout de la GPL. Il refuse que le kernel passe en GPLv3 vu ses implications. Si tu veux un vrai produit libre ou le libre est mis en avant, utilise The Hurd (enfin essaye). Et sinon il n'y a aucun "lien" entre l'userland et le kerneland, juste quelques interfaces de communication. Si on peut utiliser des logiciels propriétaires sous GNU/Linux, c'est parce que la FSF a pas osé mettre sa glibc sous GPL :).

La liberté, comme la paix n'est jamais acquise (même et surtout dans nos "démocraties" modernes). Tout a un prix et il faut se battre au quotidien pour les maintenir. Croire qu'en imposant le libre via la GPL, on résoult le problème, c'est à mon avis une erreur.

Free.fr utilise peut-être une version patché de linux. La GPL ne t'assure pas du tout qu'ils enverront en upstream. La GPL impose des choses lors de la distribution, pas l'utilisation. Free.fr peut continuer à utiliser son Linux patché aussi longtemps qu'il veut, GPLv2, BSD ou licence proprio.

Ces frameworks assurent il que les pages sont valides, que les liens marchent, etc ... ?

Il faut à mon avis voir ça comme la proof du concept que ca marche et que c'est bien. Rien n'empeche de rajouter une couche par dessus qui encapsulera complétement la notion de html / formulaire / lien, mais en profitant des avantages existant déjà, en particulier la conformité.

Je pense que Linus dans son speech pour Google a aussi cité pas mal de cas intéressant.

Je reprends quelques points :
- dans la majorité des entreprises, avant de commiter des choses dans le dépôt central, il faut passer un tas de tests de non-regression (ce qui est long et chiant). L'effet pervers de la chose dans un système centralisé, c'est que les gens tendent à commiter d'enormes changeset à chaque fois, et pas forcement des trucs atomiques. dans un système décentralisé, tu continue de faire tes commits atomiques dans ta branche locale, et quand tu veux pusher tes changements dans le dépôt central, tu passe les tests de non-regression ( et git-bissect t'aide à retrouver pourquoi ca foire, soit dit au passage)).

- si deux développeurs travaillent sur une partie de code commun, tu peux soit créer une branche sur le dépot central (avec les problèmes que ca a, dans le namespace commun, et puis la facilité de merger des branches dans cvs/svn, n'en parlons pas), soit ils travaillent sur une branche local, et se pull/push les patchs

enfin je laisse linus faire sa pub, il est plus percutant et drole que moi.

Quand au confort d'utiliser git par rapport à cvs/svn, c'est sans commune mesure. Les opérations communes sont bien plus rapides et donc transparentes (opération de diff, opération de commit (vu que c'est local), visionnage de l'historique, merge de branches, tag, ...)

Autant pour moi. La question reste entière pour le suivi de la branche 4.2 ou des futures branches de gcc. Plus globalement, savoir si il y'a eu un débat sur l'intégration de code GPLv3 pour le projet FreeBSD (qui eux aussi sont des méchants qui aiment pas le libre, c'est bien connu).

Que fera-t-on si on ne veut pas continuer à distribuer simplement une nouvelle version de gcc ? Probablement, on restera sur cette version de gcc en attendant mieux. A savoir une emergence réelle de pcc (j'y crois pas), ou de llvm-c/c++ (avec le méchant apple qui se sert du libre). (Sinon la GPLv3, c'est une vraie progression ... (ou pas))

A propos de gcc 4.2, j'ai deux questions (pour lesquelles tu ne pourra pas forcement repondre).

- Intégration de OpenMP facile dans FreeBSD ?
- Intégration de code sous GPLv3 n'a t il pas posé des problèmes légaux dans FreeBSD? ou du moins suscités des questions ? Je demande ça parce que pour le projet NetBSD, ca a pas l'air si evident que ça. On a fait appel à des avocats spécialisés sur ce genre de question, et de nombreux utilisateurs / développeurs continuent à se poser des questions sur la viabilité de la chose ? (en particulier dans l'embarqué).

(oui NetBSD, c'est un vrai méchant projet plein de barbus qui aiment pas le libre, bien sûr).

Openssh serait sous GPL, ca changerait vraiment le comportement des utilisateurs ? Tu pense qu'il y'a beaucoup de gens qui modifient openssh ? Pour un usage non-inter-entreprise (et là la GPL ne peut rien pour toi).

La CDDL est compatible avec la BSD, parce que la CDDL n'est pas contaminante. On peut lier de la CDDL avec du code BSD sans problème. D'ou la possibilité d'avoir ZFS sur FreeBSD. (à faire vérifier par un juriste parce que la CDDL c'est aussi lisible que la GPL:))

[HS]
Tu ne devrai pas te fatiguer à répondre à IsNotGood. Moi je me tais et je me contente de le moinser (je lis le commentaire quand même en général, mais vu la qualité général de l'oeuvre du bonhomme).
[/HS]

C'est marrant. On pourrait appliquer la même chose à la GPL. La GPL impose que le code soit diffusé au client, pas à l'ensemble de la communauté. La majorité de l'argent en informatique c'est du service intra entreprise. Donc y'a plein de code GPL qui circule et qu'on ne verra jamais. Ces mêmes sociétés se font des couilles en or sur le code GPL. Si les Ipod tournaient sous un Os GPL, tu crois vraiment que ca changerait son destin de faire gagner des Milliards à Apple ? Pour quelle contribution d'apple ? 3 drivers ? La GPL n'empeche pas les entreprise de se faire des couilles en or avec le code associé.

Apple a leeché du code BSD pour faire son MacOSX. Whaou c'est horrible. N'empeche que ca fait une plateforme Posix de plus, donc beaucoup moins de code chiant à se retaper. MacOSX aurait ete basé sur disons GNU/Linux. Ca aurait changé quoi ? Rien, la couche AQUA/COCOA est assez largement séparé du reste pour qu'il n'y ait aucun besoin de l'ouvrir.

Je ne vais pas continuer les contre exemples.

La licence BSD a plusieurs avantages. Tout le monde peut la comprendre. Je passerai sur tous les gens qui foutent leur code sans GPL sans même l'avoir lu, se contentant du résumé des 4 libertés de Stallman. Deuxiement, la première des libertés, c'est la liberté de choix. Imposer la liberté, ce n'est pas mieux qu'une dictature de la "liberté", ca n'a pas de sens. Et en plus c'est contre productif, parce que les gens ne se posent plus de questions. Combien de GNU/Linuxien, au combien adepte du libre, utilise quotidiennement .doc, flash, le protocole msn, hotmail, les mp3z ...

Il ne semble pas que la GPLv2 protège de la DRMisation, Tivolisation et cie :). Et la majorité des projets sont encore distribués sous GPLv2 (ou later). Ah oui la fameuse GPLv3, encore plus illisible que la version précédente a écrit des trucs spécifiques pour ces cas particuliers (et je suis sur que ces salauds de devs^W avocats proprios vont trouver rapidement un moyen de contourner).

Le code BSD reste libre, autant que le code GPL. Clairement quand des gens qui font du proprio prennent du code BSD, ca ne lèse personne au final. Il vaut mieux qu'ils réutilisent du bon code libre que d'écrire du mauvais code (pour tout le monde).

Quelques remarques :
- je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier

- perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.

- si le développeur est incompétent / négligeant / ignorant, mon premier souci n'est probablement pas celui que tu décris, sachant que les disques durs ca lache pas si souvent que ça. Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).

- git est écrit pour Linux, mais tourne concretement sur n'importe quel système Posix. Pour Windows, il reste du boulot, je ne sais pas trop où ils en sont. Je n'ai personnellement pas d'action pour git. Hg, monotone (on l'avait pas encore cité), bazaar-ng ou cie, je n'en ai cure, tant que c'est décentralisé (il se trouve que là ou je travaille, on utilise plus git qu'autre choses).

Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), je dirai qu'il s'agit surtout là d'un problème humain, de l'incapacité de 5 gars dans un même bureau à se parler alors que des centaines de personnes arrivent à le faire sur des projets libres de tailles importantes. Chercher l'erreur. Alors oui svn permet de mettre un lock technique au manque de communication, mais ce ne résoult guère le problème en général.

Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.

Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?

J'ai juste dit que globalement, les opérations de bases sont plus rapides sous git (et on rajoute tout ce qu'on peut faire sans avoir accès au serveur de synchro). Comme c'est un outil, et que ca ne prend que 3-4 jours à l'apprendre (et encore, les commandes de bases, bah elles se ressemble toute), git add, git rm, git diff, git commit....

Les projets sur lesquels j'utilise git sont des petits projets. Le gros projet sur lequel je bosse utilise hélàs un outil largement depassé (CVS) et j'espère qu'on switchera vite.

git permet je pense d'aller plus vite (pour le développement, je ne parle des autres cas cités précédemment) au cout d'une certaine discipline humaine.

Quand à savoir qui a la plus grosse, je te la laisse :D

Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?

Pour la documentation, je te laisse le soin de faire un man git-bisect, tout est très clairement documenté (ici par exemple http://linux.die.net/man/1/git-bisect)

git contrairement à svn est documenté par des pages man ...

L'avantage de svn ici c'est que les changesets sont consécutifs, donc la bissection est plus aisée.

Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl. On a rarement l'occassion de voir des outils plus Unix, et plus faciles à customiser.

convert avec l'option -draw (de ImageMagick bien sûr doit pouvoir faire ce que tu veux). Après je sais pas si la finesse du résultat te satisfera, je l'utilise pour des trucs assez grossiers.

Tous les outils que tu utilise sont géniaux, les autres sont forcément moins bon vu que tu les utilise pas. Je suis sur qu'on peut te decerner sans problème la palme du meilleur trolleur de LinuxFr 2007 et 2008 (j'anticipe mais tu es bien parti).

Tu as prouvé ta méconnaissance de git dans ce thread, n'en rajoute pas. svn est correct. git est juste mieux, plus rapide pour les opérations courantes, possibilité de tout faire hors-ligne et de push plus tard, et à des trucs supers avancés comme bissect.

Je vois mal le rapport entre svn switch est git-bissect (ou hg bissect).

Avec bissect, tu definis deux tags good et bad (l'un tu es sur que ca marchait, l'autre tu es sur que ca marche). Il prend un changeset au milieu, revient à cette état, tu test ton bug et tu marque cet etat good ou bad. Et ensuite, on recoupe, jusqu'a trouvé le commit qui introduit le bug.

C'est faisable avec un SCM classique, à la main, mais c'est très chiant.

Je pensais que les vrais administrateurs partaient très loin en courant quand on leur parlait de sudo. Un logiciel setuid qui fait des choses aussi complexes, ca a de quoi faire peur. Surtout quand les patchs se succèdent. Et surtout depuis que Watson a identifié des possibles races conditions en Août 2007 permettant de faire des choses pas belles (http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi(...)

Enfin sinon je comprend ce que tu voulais dire, le jamais était juste de trop (et je vois mal la différence entre un su - et être loggué en root).

Euh ils travaillent comment les administrateurs unix alors ?

Xen n'est pas intrusif dans un système portable. Typiquement NetBSD a ajouté arch/xen et basta (modulo la correction de bugs detectés par Xen, par exemple dans la stack réseau). Par contre, FreeBSD ou Linux ont une architecture moins portable et ca leur pose des problèmes (en général dans la gestion de la vm).

Sinon je ne répondrai pas sur le reste. Tu es trop trollifère tout seul.

Linux n'est pas portable, mais il est beaucoup porté. Je te laisse essayé de comprendre la différence.