NdM : ce qui agace certains, et motive le blacklistage de RMS, est son insistance à tenir un débat non technique sur la liste technique kernel, rien d'autre. On a déjà parlé de bitkeeper ici (voir dépêche précédente). Pour résumer, il s'agit d'un outil de gestion de versions (au même titre que CVS, mais en - paraît-il - plus pratique) que Linus a choisi d'utiliser pour le développement du noyau.
Le problème est que, si une version gratuite est disponible, sa licence est tout sauf libre, et par exemple le fait de développer un "concurrent" empêche d'en profiter.
Richard Stallman n'a bien entendu pas manqué de faire connaître son opinion à ce sujet, ce qui a déclenché une énorme flame war sur la mailing-liste du noyau....
Aller plus loin
- L'article (30 clics)
- Dépêche précédente (25 clics)
- Le thread "Blacklist rms@gnu.org" (52 clics)
# Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
C'est beau, c'est frais. Quand les développeurs noyau se demande s'il ne faudrait pas plonker RMS de la liste parcequ'il leur reproche d'utiliser un logiciel non libre ( http://www.bitkeeper.com/(...) ) pour gérer les sources, on est en droit de se demander où cela finira.
Certes, les excuses ne sont pas mauvaises ("il n'a jamais posté un mail OT" -> ce qui est faux, mais passons), mais faut il craindre d'autre dérives? Nous savons que Linus n'est pas un grand supporter de la philisophie du libre, mais il ressort que certains des développeurs noyau ne le sont pas non plus.
Alan Cox a pris la défense de RMS, ce dont on ne peux que se réjouir.
Je tiens de plus a effectuer une petite rectification pour les amateurs de trolls BSD/GPL: la GPL a pour but de défendre la liberté des utilisateurs, pas celle des développeurs. Linux est GPL, mais ne fait pas parti du projet GNU (qui impose d'autres contraintes, comme une déclaration de l'employeur comme quoi il abandonne ses droits sur le projet du développeur).
Moralité: Utilisez Ze Hurd.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Nelis (site web personnel) . Évalué à 1.
J'imagine bien un certain S. Ballmer :
"Linux ? Un concurrent ? Nooon ! Ils se sont rendu compte de l'inéfficacité de leur <<utopie>> : ils utilisent aussi des logiciels propriétaires maintenant !"
Enfin, c'est juste mon avis ...
Nelis
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par phq . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Code34 (site web personnel) . Évalué à 1.
Hier, Linus se tournait vers bitkeeper un soft propriétaire pour développer le noyau Linux, aujourd'hui Stallman (representant/initiateur du logiciel libre) se fait blacklister de la liste de développement du kernel.
Comme je le disais dans mon ancien post, ça en dit long sur la nouvelle philosophie/dérive qui est entrain de s'instaurer sous linux.
-> introduction des méthodes de développement à la logiciel propriétaire, guerre des grands seigneurs censeurs ...
Alan Cox a raison de rappeller à l'ordre certains intervenants de la mailing list en leur demandant qui ils sont pour prendre de tel décision...
Le problême pour Stallman c'est qu'il mène plusieurs gros combats en meme temps, et en se faisant des énemis à droite à gauche, il risque de s'isoler. En même temps, si ça s'envenime, ça risque de définitivement partager la communauté linux (il y aura t il un fork ou une migration en masse vers un autre système?)
code34
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par tcws . Évalué à 1.
(blague -1)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . Évalué à 1.
Subversion est utilisable. CVS aussi (et beaucoup de gros projets s'en contentent). Mais ne crois-tu pas qu'il sera un peu trop tard ? Avec toutes les méta-données sur Bit Mover, tous les devs habitués à utiliser BK, ... ? Et ne crois-tu pas que les devs vont préférer ne pas intégrer ce genre de patchs plutôt que de remettre en cause leurs habitudes de travail ?
Et que dire pour Alan, Andrea, Rik, ... qui légalement n'ont pas le droit d'utiliser Bit Keeper puisque leurs employeurs diffusent CVS (et peut-être un jour Subversion) ? Larry a dit qu'il _permettait_ aux développeurs du noyau payés par une distribution de continuer à utiliser Bit Keeper... mais le texte exact de la licence dit le contraire. Alors ? On fait quoi ?
Ce que dit RMS, c'est que le logiciel libre est dangereux. Qu'il peut toujours se retourner contre l'utilisateur, et qu'accepter de l'utiliser c'est accepter des chaines et de dépendre du bon vouloir d'une société. Bien sûr, on peut toujours changer après, si la nouvelle licence ne plait pas. Mais ça veut dire abandonner ses habitudes de travail, souvent perdre des données d'une manière ou d'une autre, ...
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
Bon gros lapsus
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par furai (site web personnel) . Évalué à 1.
Et hop, une fortune de plus !!
^_^
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par kadreg . Évalué à 1.
Mr X ne peut utiliser bitkeeper si lui ou son employeur développe, produit, vend ou revend un logiciel ayant des capacités similaires à bitkeeper.
Résultat :
- Les gens qui développent un gestionnaire de conf (notamment ceux de subversion) ne peuvent utiliser bitikeeper
- Les gens employé par les distrib commerciales ne peuvent pas (la distrib contenant CVS). Je doit reconnaitre que c'est sujet à interprêtation, mais le doute en droit, c'est pas top.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
Ou alors, je comprends mal le terme de "version". Mais je pense pas.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par matiasf . Évalué à 1.
Mais Subversion est un gestionnaires de configuration (bien que j'ai horreur de ce terme). linux conf est un gestionnaires de configuration et en plus gestionnaire de version :-) .
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par #3588 . Évalué à 1.
Effectivement c'est faux, l'interdiction concerne bien plus que ça et est un réel problème.
L'auteur de BitKeeper prétend le contraire et essaie de se faire bien voir, mais sa licence est différente et beaucoup plus restrictive que son discours, et curieusement il refuse de la clarifier, cette licence, qui est le seul texte de référence.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . Évalué à 1.
/me a honte
/me retourne faire du C++ pour expier
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par François Romieu (site web personnel) . Évalué à 1.
[...]
Ah, les métadonnées...
ftp://nl.linux.org/pub/linux/bk2patch/(...)
Le truc vraiment petkouille avec BK, ce sont les threads à la con qu'il déclenche sur la l-k.
--
Ueimor
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par matiasf . Évalué à 1.
[^] # Re: fork avec 2 Linuxs: ceux qui aident CVS et subversion, et les autres
Posté par free2.org . Évalué à 1.
Tous les développeurs qui participent de près au de loin au développement de CVS, Subversion, Webdav, etc.. n'ont plus le droit de participer au développement du noyau Linux. Je soupçonne qu'Alan Cox pourrait bien être dans ce cas, d'où son soutient à RMS sur une mailingList pourtant technique en effet.
On se dirige donc vraiment vers un fork de Linux: d'un côté ceux qui n'ont pas le droit d'utiliser Bitkeeper à cause de leur participation à CVS, avec pour leader Alan Cox (qui a probablement + contribué à Linux ces dernières années que Linus Thorvalds).
De l'autre ceux qui n'ont rien à faire de la promotion des logiciels libres, avec pour leader Linus et quelques boites commerciales qui se frottent les mains d'avance.
Au final, RMS a encore raison: utiliser des logiciels non libres finit toujours par couter beaucoup plus cher que le simple prix de leur licenses.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . Évalué à 1.
[^] # un texte à commenter ?
Posté par Anonyme . Évalué à 1.
Ca commence par :
« At issue initially was Bitkeeper's restriction on how the free-of-cost version of the program may be used, though some had always been uncomfortable about use of a product in kernel development when that product is not itself published under the GNU General Public License. When restrictions in the BitKeeper license came to light, Stallman commented to the Kernel development list that this is what happens when software is employed that is not free by the Free Software Foundation's definition »
On remarque que selon cet article, certains ne sont pas content de BitKeeper par ce qu'il n'est pas publié selon la GPL, et que RMS évoque ce qui arrive lorsqu'un logiciel n'est pas libre selon le point de vue de la FSF.
On en comprend que :
1) ceux qui n'aiment pas BitKeeper sont des fanatiques qui a priori n'acceptent que la GPL.
2) BitKeeper pourrait ^etre considéré comme libre, selon une autre définition (difficulté : le by the FSF's definition est-il là uniquement pour dire qu'il ne s'agit pas de "free as beer" - si c'était le cas, je pense que le "free as freedom" aurait été employé).
Le premier paragraphe nous raconte donc que c'est une querelle entre supposés fous furieux pro-FSF et un logiciel qu'on n'ose pas qualifier de logiciel propriétaire (première occurence du terme dans une citation).
La suite de l'article évoque les reproches généralement fait à la GPL. Qui sont à proprement parler completement hors-sujet.
Ce procédé permet effectivement de déporter le débat sur les questions purement philosophique, « software licensing philosophy ».
Ce qui fait apparaitre la discussion en parfait hors-sujet sur la liste du noyau...
Ce qui permet d'introduire le message de Larry McVoy, de BitKeeper:
« "It's not a free speech issue, it's a question of whether this is the place for that sort of discussion. We could discuss pro-choice vs pro-life here as well but we don't, this isn't the place for it." »
En effet, comme cela surprend, ce monsieur considère que la liste de discussion du noyau n'est pas l'endroit approprier pour évoquer les outils utilisés dans le développement du noyau...
Et pourquoi ?
Seule la fin de l'article semble rattraper le reste.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par boris . Évalué à 1.
On pourrait dire que RMS a lui aussi ete quelque peu indelicat.
Dans le fond, il a raison. Cet homme se bat pour ses idees, il donne vraiment tout ce qu'il a pour les defendre.
Mais sur la forme, il passe limite pour un integriste, rejetant en bloc tout ce qui n'est pas GNU/GPL like. Et sur la forme, justement, il est un peu agacant.
BK n'illustre pas -a mon avis- une derive ou quoi que ce soit; les developpeurs ont trouvé la un outil qui leur epargne pas mal de peine. Gageons que dès qu'un LL faisant la meme chose sera disponible, ils se mettront a l'utiliser. Dans cette affaire, tout le monde y trouve son compte, les developpeurs du noyau, et l'editeur de BK, car le fait que son logiciel serve au developpement de linux lui fait un enorme coup de pub.
Alors au lieu de raler, on court contribuer au developement d'un BK gpl, et tout le monde sera content.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par #3588 . Évalué à 1.
Ah bon, apparemment il parle plutot de sa définition du libre. La GPL n'est qu'une licence parmi d'autres, se conformant à cette définition, et la définition n'exige certainement pas de copyleft. Où est-ce qu'il dit que le libre non-GPL c'est Mal(TM) ?
« Dans cette affaire, tout le monde y trouve son compte, les developpeurs du noyau, et l'editeur de BK, car le fait que son logiciel serve au developpement de linux lui fait un enorme coup de pub. »
Tu oublies quelques développeurs comme Ben Collins, Alan Cox, etc. Eux n'y trouvent pas leur compte, non.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
Comme j'essayais de le démontrer plus haut, l'article mis en premier lien de cette dép^eche incite très nettement à voir les choses ainsi.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par pasBill pasGates . Évalué à 1.
Il n'y a aujourd'hui pas d'outil libre qui permet de faire ce que permet BitKeeper, faut il donc utiliser des methodes 3x moins efficaces, perdre du temps, s'enerver,... uniquement pour des raisons "politiques" ?
Utiliser du libre c'est bien quand c'est disponible, le jour ou une alternative libre existera, je comprendrais a la limite que les gens pressent les devs de changer, mais d'ici la ca revient plus a faire chier les gens qu'autre chose.
Ceux qui gueulent feraient mieux de coder une alternative libre plutot qu'emmerder des gens sur le choix de leurs softs, qui apres tout ne regarde qu'eux.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par phq . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par astennu . Évalué à 1.
Si Bitkeeper est vraiment mieux, il faudrait que cela tire CVS par le haut afin de pouvoir remplacer bitkeeper. Je ne sui pas spécialement pour imposer l'utilisation des logiciels libre (ma copine utilise Win XP et je le vis bien, même mieux qu'elle :: ça plante tout le temps!), mais qu'un des piliers des logiciels libres comme Linus Torvald utilise du proprio pour son projet open source principal, c'est dur à accepter.
[^] # qu'un des piliers des logiciels libres comme Linus Torvald ....
Posté par Unixfix le Gaulois . Évalué à 1.
Les defenseurs du libre oublient volontairement que Linus n'a jamais que developpe une alternative aux unix proprietaires hors de porte de sa bourse d'etudiant.
[^] # Re: qu'un des piliers des logiciels libres comme Linus Torvald ....
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: qu'un des piliers des logiciels libres comme Linus Torvald ....
Posté par Code34 (site web personnel) . Évalué à 1.
code34
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par matiasf . Évalué à 1.
C'est une très bonne raison. la "politique" est très important.
> le jour ou une alternative libre existera ...
Subversion est en développement avec le soucis, entre autre, de pouvoir "virer" BitKeeper. S'il y a une forte communauté free software, l'idéal serait d'aider au développement de Subversion.
Pour ma part je suis à fond avec Linus car il n'y a pas de problème concrèt dans l'utilisation de BitKeeper et que çà fait avancé le développement du noyau.
Et je suis à fond avec RMS car la défense du free software est le plus important.
RMS défend une idéologie, un idéal et doit donc être idéaliste :-) .
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par khalid . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par #3588 . Évalué à 1.
Oui, il l'a expliqué, sa start-up est là pour son intérêt financier, pas pour l'intérêt du kernel. Il suffit de voir à quel point on a l'impression de lire 2 personnages différents, suivant qu'on parle ou non de BitKeeper. Sa réponse à Ben Collins donne quand même pas mal d'indications sur son vrai visage, et ça devrait plutôt inciter à se méfier très sérieusement de lui.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Toufou (site web personnel) . Évalué à 1.
Il existe des solutions libres assez proches, sauf erreur, et ce serait l'occasion de les perfectionner et d'avoir au final un produit adapté nickel au developpement du kernel. C'est comme d'habitude, quoi: il faut accepter une perte de temps immédiate pour des gains de temps et d'outils énormes sur du moyen terme.
Et puis bon, qu'est-ce qu'une perte de temps sur un soft libre ? C'est bien quand ça avance, mais après tout, le développement de linux n'est pas fait pour être rentable, non ?
emmerder des gens sur le choix de leurs softs, qui apres tout ne regarde qu'eux.
Je suis tout a fait d'accord sur le fait que les gens utilisent ce qu'ils veulent. Si RMS n'aime pas le soft utilisé par les dev kernel, beh qu'il ne l'utilise pas !
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par boubou (site web personnel) . Évalué à 1.
Concernant la rapidité de développement, c'est bien entendu très important. Comment veux-tu que le noyau soit à jour en terme de drivers si linus passe des heures à patcher ? Pour que Linux attire des gens, il faut que le maximum de hardware soit supporté et ce le plus rapidement possible. Il faut donc que le développement soit rapide. Si BitKeeper aide, c'est plutôt bien.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
Avec des réflexions comme ça, Linux, le projet GNU et tout un tas d'autres logiciels libres ou open sources n'auraient jamais vu le jour.
Il y a 5/6 ans, Linux ne valait pas OS/2 ni Windows. On aurait dû abandonner Linux? Je ne pense pas.
Le choix de bitKeeper me gène d'autant plus que ce que tu as dit est justement de Linus, et qu'il me semble qu'il ait la mémoire courte.
Je ne suis pas contre les logiciels propriétaires, mais je pense que là, les défenseurs du logicile libre comme RMS sont en droit de faire la réflexion, et les détracteurs sont en droit de dire: "voyez, ils développent Linux, mais finalement ils utilisent des logiciels propriétaires".
Formidable.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par boubou (site web personnel) . Évalué à 1.
D'autre part, je ne suis pas du tout d'accord avec toi, il y a 5/6 ans linux était déjà bien meilleur que windows et qu'OS/2, ça dépendait seulement du domaine. Personnellement, je n'utilise que linux depuis 1994 (sauf pour les jeux...) et merci, tout va bien.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par anonyme512 . Évalué à 1.
En fait, tout ça me rappelle un peu ce qui s'est passé au moment ou Netscape a ouvert son code source:
Les développeurs, la communauté, etc. se sont rendus compte que c'était .. disons.. de la merde. Donc ils se soont dit qu'ils allaient repartir du début.
Et là nouveau problème, ils se sont aperçus qu'il leur manquait un paquet d'outils pour refaire convenablement un tel développement.
Le projet Mozilla a donc accouché de Bugzilla (entre autres). Mais en contrepartie, il en a salement pris dans la vue en terme de délais: pendant que les développeurs font ce genre de développements "annexes", ils ne font pas le développement central.
Le cas de Linux est donc assez épineux de ce point de vue, car on est dans une phase assez critique où le support matériel est plus que jamais important. Doit-on perdre du temps sur Subversion, de manière à avoir un logiciel de gestion des sources qui soit libre, au détriment de l'implémentation plus que nécessaire de certains modules (ou du moins une augmentation considérable des délais) ?
Les délais c'est important, car c'est aujourd'hui que Linux doit convaincre. Demain, avec Palladium & Co., il sera trop tard.
L'attitude de Stallman, c'est exactement la même depuis le début: il s'en fiche des délais, pourvu d'être conforme à son idéologie tout le temps. Parfois c'est bien, mais force est de constater que le système GNU n'est pas tout à fait une réalité (même si le Hurd, doucement..), et que le "projet" de la FSF a quand même été vachement aidé par Linus et ses potes, ainsi que par des boites commerciales sans rapport avec la FSF (distros, trolltech, IBM, Sun, etc.)
Bref, en conclusion, c'est quand même un beau sujet à troll, vu que les deux (RMS et LT) ont raison à leur façon...
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Delahaye Matthieu . Évalué à 1.
Faut faire gaffe avec le mot délais. ça fait sujet à troll genre traduction "précipitation" au lieu de "rapidement". Et dans le genre précipitation on obtient des jolis résultats à la Microsoft ou Hardware buggé.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Toufou (site web personnel) . Évalué à 1.
Le seul intéret que je vois à la popularité de linux (ou de tout autre soft libre) est le poid qu'ont ses utilisateurs (tant politique qu'économique), ce qui pourrait être utile pour défendre le libre dans le contexte actuel (loi délires, etc). Je vois donc la popularité de linux comme un aspect important, mais pas comme une fin en soi. Mais bon, du coup je trouve quand même un peu contradictoire de vouloir gagner des 'parts de marché' mais ne pas vouloir s'occuper des aspects politiques*.
Peut-être n'ai-je pas compris pourquoi linux devait être si populaire ?
*) Comme privilégier du propriétaire parce que c'est plus efficace plutot que de se ralentir afin d'améliorer et d'adapter les alternatives libres à de nouveaux besoins.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par #3588 . Évalué à 1.
C'est en général de la mauvaise foi que de dire ça. Non pas que les solutions libres soient équivalentes, on peut effectivement juger BitKeeper meilleur, c'est ce qu'a fait Linus. Mais dire qu'il est impossible d'utiliser du libre pour cette raison, surtout quand ça vient de la part de Linus, c'est du foutage de gueule. Il a mis très longtemps, malgré les demandes des développeurs, à utiliser un tel logiciel d'aide. Bref, il se passe volontiers de ce genre de logiciel pendant longtemps, et soudain BitKeeper est indispensable ?
Quant au fait que ce soit 3 fois moins efficace, on peut en douter. Pour ceux qui utilisent BitKeeper, peut-être. Mais pour ceux qui ne le veulent pas, ou ne le peuvent pas, c'est largement moins efficace que s'il y avait CVS ou Subversion. Bref, dire que c'est moins efficace, c'est ne s'intéresser qu'aux développeurs utilisateurs de BitKeeper et mépriser les autres.
« uniquement pour des raisons "politiques" ? »
Où ça des raisons politiques ? On peut ne pas vouloir utiliser un logiciel propriétaire tout simplement parce que c'est dangereux, et pas uniquement pour des raisons politiques. Le caractère libre d'un logiciel, c'est aussi un aspect technique (c'est tout l'objet de l'Open Source) et ça peut très bien être considéré indispensable indépendamment de tout point de vue politique sur les logicels. Les développeurs du kernel qui ne veulent pas de BitKeeper ne disent pas « tout logiciel doit être libre », ils disent « je ne peux/veux travailler qu'avec du logiciel libre ».
« Utiliser du libre c'est bien quand c'est disponible, le jour ou une alternative libre existera, je comprendrais a la limite que les gens pressent les devs de changer, mais d'ici la ca revient plus a faire chier les gens qu'autre chose. »
Utiliser BitKeeper, donc ne pas utiliser principalement CVS ou Subversion, c'est gêner ceux qui n'utilisent pas BitKeeper. Ils peuvent bien sûr travailler comme si de rien n'était, puisque les patches sont créés "comme avant", mais pour eux il n'y a pas eu de progrès là où il y aurait pu en avoir pour tous.
« Ceux qui gueulent feraient mieux de coder une alternative libre plutot qu'emmerder des gens sur le choix de leurs softs, qui apres tout ne regarde qu'eux. »
Ce choix concerne l'ensemble des développeurs du noyau et les affecte, ça ne regarde certainement pas que Linus : c'est lui qui décide ce que les autres pourront utiliser comme logiciel. Ce n'est certainement pas une situation dans laquelle chacun choisit ses outils comme il l'entend, contrairement à ce que tu veux faire croire.
Ca résume bien tes posts sur cette histoire, excessivement simplistes et oubliant comme par hasard tous les inconvénients qui retombent sur ceux qui ne peuvent pas utiliser BitKeeper. Avec en prime une insulte lancée aux codeurs d'alternatives libres (oui, même s'ils gueulent, ils codent) et/ou du kernel (oui, ils codent aussi).
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
En revanche, CVS et Subversion ont été conçus pour du développement collaboratif. Sur le CVS de gros projets, plusieurs dizaines de personnes ont un accès en écriture, et ça se passe très bien.
Bitkeeper a beau avoir amélioré la cadence pour Linus, viendra un moment où il ne pourra plus suivre, si le rythme des patches et la taille de la source continuent d'augmenter. Peut-être qu'à ce moment-là il se rendra compte que le développement collaboratif est supérieur.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par matiasf . Évalué à 1.
Subversion le fait trèèèèès bien. Mais la méthode est différente.
Linus a un dépôt perso. Les autres développeurs peuvent envoyer des patchs subversion et il les applique.
Je doit reconnaitre que cette partie de subversion n'est pas finalisée (il doivent bosser sur un nouveau format de patch (supportant l'ajout de répertoire, le renommage de fichier etc...). La possibilité actuelle est de faire :
$ svn merge -r version_initial:version_final [dépot alan cox]
çà demande d'avoir un serveur subversion côté alan cox (comme pour les autres dev). Mais il y a le support de renomage de fichier par exemple ...
Je connais Subversion et à moyen terme, "çà le fera". Par contre, l'auteur du patch est actuellement perdu (domage).
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Cite-moi un exemple qui prouve que le developpement collaboratif est supérieur ? Cite moi un projet ou n'importe qui peut committer n'importe quoi n'importe où ?
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par #3588 . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Si c'est dans ce sens là que tu entends "collaboratif", alors oui, on est d'accord. Et c'est déjà ce qui se passe pour Linux, dans le sens ou il y a un petit nombre de gens qui s'occupent de sous-parties du kernel et auxquels Linus fait confiance pour les patches. Linus ne traite évidemment pas tout seul tous les patches qui sont postés.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Eddy . Évalué à 1.
Ah oui, ca marche pas.
Tu as raison, alors.
P.S. C'est trop cool qu'il n'y ait plus de cotes, on peut dire n'importe quoi sans risque.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non. Il n'y a que 2 ou 3 personnes qui committent pour chaque composant (gnome libs, gtk, etc...). Et encore, ça leur prend beaucoup de temps pour stabiliser lorsqu'il décident de faire une release.
Essaie encore.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
# Re: Bitkeeper, RMS et PLONK.
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Jaimé Ragnagna (site web personnel) . Évalué à 1.
# Re: Bitkeeper, RMS et PLONK.
Posté par oliv . Évalué à 1.
Le pluriel est exagéré ici.
Une seule personne a demandé celà (C. H.), et toutes les réponses ont été négatives (voire très négatives)
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Gaël Le Mignot . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Anonyme . Évalué à 1.
# C'est pas si compliqué
Posté par Arachne . Évalué à 1.
AMHA Trois solutions :
1) Fork du kernel : Arghh! Trouver des dev qui lachent Torvalds c'est pas évident (surtout quand on connait le nb de dev actifs du Hurd)! Complètement surréaliste, on oublie.
2) Développer une alternative libre à BitKeeper, qui soit gravement trop mieux, et surtout QUI PLAISE A LINUS. Et là il abandonnera son BitKeeper.
3) Liquider Linus : c'est pas forcément la plus mauvaise ;)
Oui nous ne sommes que les esclaves de ce pingouin finlandais, mais on n'a pas le choix : laisser tomber Linux c'est retarder de plusieurs siècles l'avènement du vrai Choix de l'utilisateur entre le Libre et le Proprio.
Sur ce, j'installe subversion.
[^] # Imbécile !
Posté par Samuel Pajilewski . Évalué à 1.
C'est facile de critiquer, d'insulter les autres et se prendre pour dieu le père, mais quand on est pas fichu de donner une alternative à BiteKeeper on ferme son claque merde !
La mailing liste du kernel est une ML technique basée sur les conception et realisation du noyau.
La politique et la phulosophie n'a rien à faire la dedans, qu'il retourne jouer à sa merde de Hurd et laisse les vrais developpeurs travailler !
[^] # Re: Imbécile !
Posté par Eddy . Évalué à 1.
[^] # Re: Imbécile !
Posté par kadreg . Évalué à 1.
[^] # Re: Imbécile !
Posté par Eddy . Évalué à 1.
[^] # Re: Imbécile !
Posté par kadreg . Évalué à 1.
[^] # Toi même !
Posté par TSelek . Évalué à 1.
Insultes, dénigrement, amalgame, bref on voit que le système des XP est en pause...
[^] # Re: Toi même !
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Imbécile !
Posté par tcws . Évalué à 1.
> BiteKeeper on ferme son claque merde !
cite une seule personne qui soit "fichu de donner une alternative à bitkeeper"... tu as dix secondes.
2...1...0 personne ? tout le monde ferme sa gueule alors ? <troll>et les développeurs libres ils mettent le palladium le papier alu ?</troll>
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Imbécile !
Posté par #3588 . Évalué à 1.
Bien sûr que si il a donné une solution, et d'autres l'ont fait avant lui.
[^] # Re: C'est pas si compliqué
Posté par f l . Évalué à 1.
"When Code Matters more than Commercials"
en gros... le code est plus important que le marketing.
Pas mal des arguments dans les commentaires disent 'Ca la fout mal que linux, l'embleme du LL soit développé avec un soft non libre'.
Tu parles de "Symbole" et "d'image"; tu parles de marketing en fait, le marketing de linux.
De son coté, Linus, n'a, je crois, jamais voulu faire de linux un symbole du LL. Il a voulu développer un kernel accessible à tous, et il a reconnu que l'utilisation d'une licence libre etait le meilleur moyen d'y parvenir.
Autant que je sache, rien n'empêche de développer un logiciel libre en utilisant un logiciel propriétaire. Alors oui c'est vrai, pour le marketing, c'est mieux d'utiliser un LL de bout en bout. Mais "le code est plus important que le marketing", et aujourd'hui BK apporte un plus incontestable au niveau du code. Lorsqu'une alternative libre sera au niveau et conviendra aux devs du kernel, il sera temps de se préocupper du marketing et de changer d'outil. En attendant, le plus important c'est la qualité du code, et d'avoir le plus rapidement possible un 2.6 ou un 3.0 qui soit irréprochable.
[^] # Re: C'est pas si compliqué
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
La mercatique de BKbits, qui utilise Linux pour faire sa publicité.
[^] # Re: C'est pas si compliqué
Posté par Arachne . Évalué à 1.
Je trouve ça à la fois abérant et désopilant qu'un petit nerd récolte les fruits de ce que RMS a mis 20 ans à élaborer, et lui saborde le boulot. Je ne dis pas ça méchamment (ok un peu), mais il faut admettre que Linus n'a fait "que" développer un (excellent) logiciel libre, alors que RMS y a dédié sa vie. Après on peut être pour le Libre ou seulement s'en servir, c'est au choix.
Imaginez un instant que ce soit RMS qui aie créé Linux... je me demande bien comment les choses auraient tourné... Car quelque part l'intérêt exclusif qu'à Linus pour le code et les performances, ainsi que la "magic touch" qui lui a permit d'avoir sa tête à la une, étaient peut-être nécessaire au relatif engouement actuel. Mais peut-être pas.
[^] # Re: C'est pas si compliqué
Posté par Neryel . Évalué à 1.
Probablement plus barbues, pour commencer :+)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est pas si compliqué
Posté par #3588 . Évalué à 1.
Je t'en donne une autre, des mêmes (je l'ai vue attribuée à Bdale Garbee) : « Life is too short to use proprietary software ».
Quant à ton interprétation de cette citation... voir plutot celle de JJB hein, ceux qui ne veulent pas de BK s'en foutent pas mal du marketing.
[^] # Re: C'est pas si compliqué
Posté par f l . Évalué à 1.
Alors que c'est bien le seul truc qui compte!
Les symboles, les grandes idées, les belles phrases, les slogans, c'est bien.
Mais au final qu'est ce qui m'intéresse en tant qu'utilisateur du kernel linux:
1/ qu'il soit stable, performant, avec bcp de fonctionnalités
2/ qu'il soit libre (GPL)
L'utilisation de BK a t'elle un impact négatif sur l'un de ces 2 points?
Elle améliore le point 1, et ne touche pas le point 2.
Le reste n'a aucun impact technique, c'est du marketing, des 'commercials', et en ce qui me concerne ça va directement dans /dev/null
[^] # Re: C'est pas si compliqué
Posté par #3588 . Évalué à 1.
Sans doute sur le premier, pas sur le second.
« Elle améliore le point 1 »
Non. Ou alors il faut le démontrer. (sans oublier que la comparaison ne se fait pas avec une situation sans BK, mais avec un autre gestionnaire, voire une autre organisation).
# Linus? Not so cool!!!!!!
Posté par jeanmarc . Évalué à 1.
Ca nous permet quand même de constater que la notoriété du noyaux Linux a attiré beaucoup de développeurs qui viennent du monde commercial et qui n'ont aucun soucis de la GPL.
Le fait de voir quelqu'un de bitmover defendre sa licence propriétaire sur la liste et trouver des appuis des développeurs du noyau est symptomatique. Le loup est dans la bergerie :-)
On constate aussi que Linus n'a aucune personnalité et agit comme un gamin. Il dit être cool et ne pas vouloir faire de politique pourtant il place son logiciel sous licence GPL, la plus politique des licences! Pourquoi ne pas avoir choisit la BSD qui correspond plus à son esprit? D'autant plus que ça fait longtemps qu'il connait les implications de la GPL. Il explique lui-même qu'il ne remet pas à jour la liste des contributeurs pour qu'il soit quasiment impossible de tous les contacter pour faire passer le noyau soous une même licence. Ce n'est pas politique ça?
Concernant Bitkeeper, certains surfent sur la vague du "Linus fait ça pour le plaisir. Faites un truc équivalent et il changera.le développement va plus vite..." dénué de réflexion et d'arguments cohérents.
Ils oublient que Linus a TOUJOURS refusé d'utiliser un logiciel de gestion de version depuis le début! Le kernel n'avançait pas pour autant?
Récemment, sous la pression des dévs, il a testé plusieurs logiciels de gestion de version et a choisit celui qui répondait à ses besoins mais aussi celui qui faisait le plus chier ceux qui lui avait demandé d'utiliser cvs!
Ca lui a immédiatement été signalé et c'est là qu'il a commencé à donner sa réponse de gamin et du mec soit disant pas engagé:"j'utilise ce que je veux, vous faites ce que vous voulez" alors qu'il sait trés bien que beaucoup de développeurs seront obligés ou tentés d'utiliser bitkeeper pour rester au contact.
Dés le départ, il a été signalé à Linux que ça posait et poserait problème et que les fonctionnalités qu'il lui manquait seraient rapidement rajoutées du fait de sa notoriété. C'est comme celà que fonctionne le logiciel libre depuis le début et le noyau linux en est même le meilleur exemple. Toujours la même réponse égoiste de Linus.
La situation en est arrivée à un point ou les développeurs du kernel sont en train de se tirer dessus et celà risque d'empirer, d'en décourager certains et de lui retirer de sa légitimité. C'est une figure de la communauté du libre mais il n'est pas le seul et son choix nuit à des figures aussi emblématiques que lui. Qu'on propose de blacklister RMS fait rire certains mais la grande majorité trouve ça insultant pour l'esprit même de la communaté du libre. Ben Collins s'est fait envoyé chier par le mec de bitmover qui se met ainsi à dos toute la communauté Debian. Alan Cox prend la défense de RMS et il est quand même numéro 2 quand on parle du kernel Linux. linus est largement perdant dans l'affaire.
Le pire, c'est qu'un seul geste de sa part pourrait désamorcer cette situation ridicule. Il n'a même pas besoin de laiser tomber bitkeeper mais un simple mail aux mecs de subversion ou autre leur demandant où ils en sont ferait retomber la pression.
[^] # RMS est le responsable !
Posté par Samuel Pajilewski . Évalué à 1.
CVS est devenu obsolete, bcp de developpeurs contribuent au noyau partout dans le monde, BiteKeeper etait devenu une necessite.
Maintenant RMS fait le jeu de Microsoft : Il torpile Linux de l'interieur, et Bill Gates doit s'en frotter les mains : Linux est inattaquable de l'exteireur, donc envoyons un bouffon tel RMS foutre la merde dans le dvlt du noyau Linux !
Si au lieu de se chamailler tout le monde se serrait les coudes peut etre qu'on eviterai cette situation ridicule qui ne fait rire que Ballmer.
Merde enfin , 11 ans de boulots pour en arriver là, si c'est pas pitoyable !
[^] # Re: RMS est le responsable !
Posté par kadreg . Évalué à 1.
[^] # Re: RMS est le responsable !
Posté par tfing . Évalué à 1.
parce que là, y a des -56 qui se perdent !
[^] # Re: RMS est le responsable !
Posté par Sismiq . Évalué à 1.
Microsoft, Gates ou Balmer n'ont rien à voir dans cette histoire et Linux n'existe pas pour être le concurrent d'un autre OS. Il est la pour plaire à ses utilisateurs, au niveau technique comme au niveau de leurs libertés. L'interêt d'avoir un système GNU/Linux, c'est entre autre d'avoir un système libre avec lequel on peut utiliser des outils libres, que ça soit au niveau des applications bureautique que des applications de developpement. Et pour cela, le support, l'utilisation et la promotion d'un outil libre pour le developpement du coeur de ce système est primordial, au même titre que l'utilisation d'un compilateur libre comme gcc, que l'on doit d'ailleurs à un certain RMS (tout comme gnu emacs)...
[^] # Petite explication
Posté par Samuel Pajilewski . Évalué à 1.
Toutefois l'attitude de RMS est inacceptable, car il critique sans donner de solution.
Aussi, tu trouverai juste, toi, que Linux perde des mois en developpement rien que pour utiliser que des produits Libres pour son developpement ?
Car si ByteKeeper permet de gagner du temps en developpement, n'est ce pas un meilleur gage de reussite pour Linux et indirectement les solutions libres ?
Doit on faire l'erreur du projet Mozilla et perdre un temps precieux sans pouvoir par la suite remonter la pente en se laissant bouffer par les technos Microsoft lentement comme un Cancer infecte un malade ? (Car c'est ce qui se passe chez Mozilla/Netscape : ça ne remonte pas, ça regresse meme, et en est au stade de 4%)
Car il ne faut pas oublier qu'avec Palladium, .Net et toute l'armada Microsoft, les developpeurs Linux doivent se presser et sortir des alternatives le plus vite possible au risque de na pas palire à tout le monde !
Car si .Net et Palladium s'impose avant que Linux ne sorte ses armes secretes, il sera trop tard et tu n'auras plus que tes yeux pour pleurer !
Soyons realistes, la situation actuelle ne nous permet pas de jouer aux politico-philosophien du libre, nous sommes obliges de faire des concessions !
[^] # Re: Petite explication
Posté par Prosper . Évalué à 1.
[^] # Re: Petite explication
Posté par Anonyme . Évalué à 1.
Ah bon ?
Faire des concessions, c'est faire logiciel dépendant du propriétaire (et donc à terme, quasi-propriétaire) ?
T'es marrant quand m^eme Samuel. Ca fait maintenant plusieurs années que tu considères les utilisateurs de linuxfr.org comme des gamins de 4 ans cherchant à tout prix à abattre Microsoft pour mettre « linux » à sa place, peu importe comment.
[^] # Re: Petite explication
Posté par Arachne . Évalué à 1.
[^] # Re: Petite explication
Posté par Maxime Ritter (site web personnel) . Évalué à 1.
Ben si Kilobug, Kadreg, penso, ou d'autres piliers de linuxfr avaient posté ce que tu disais ici, tout le monde serait mort de rire... Mais la, vu tes autres postes, forcemment, on te prends au sérieux....
[^] # Re: Petite explication
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Ah ! Ah ! Ah !
[^] # Re: Petite explication
Posté par ufoot (site web personnel) . Évalué à 1.
> la situation actuelle ne nous permet pas de jouer aux politico-philosophien du libre, nous sommes obliges de faire des concessions !
Nous ne sommes obliges a rien du tout. J'attends de voir les textes de loi (francaise) qui m'obligent a faire des concessions. Tant que je les ai pas vus, j'en fais pas!
[^] # Re: Petite explication
Posté par Prosper . Évalué à 1.
[^] # Re: RMS est le responsable !
Posté par Sismiq . Évalué à 1.
De plus j'aimerais bien savoir en quoi Bitkeeper est tellement meilleur au point de ne plus pouvoir s'en passer ou d'utiliser et developper un outil libre équivalent. Sans renier ses qualités, Linux n'a pas attendu bitkeeper pour exister et être un noyau performant, et le nombre de contributeur n'a pas explosé en l'espace de quelques mois...
Evite dans l'avenir de regarder du prone en postant ici, ça te fait ecorcher les noms.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RMS est le responsable !
Posté par Sismiq . Évalué à 1.
Et une sorte d'appel d'offre dans la communauté tu libre aurait été plus utile. ça ferait au moins avancer les schmilblick pour qu'on puisse peut-être trouver un outil libre du même niveau.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Anonyme . Évalué à 1.
Mais ce Linus, il a pourtant le temps de rouler dans sa belle BM dans le Silicon Valley. Etais-ce vraiment le dernier recours, la solution de la dernière chance ?
Non, s'il l'avait voulu, il aurait très bien pu payer quelqu'un, faire une donation, pour que soit implémenté en libre ce qu'il recherchait. Mais il ne l'a pas fait. Pas envie, pas l'intention. Il en a le droit, parfaitement le droit.
Mais restons honn^ete : linus à choisi BitKeeper parce que cela était opportun pour lui. Ce n'est pas un pauvre hère à bout de souffle, utilisant BitKeeper avec un couteau sous la gorge.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Personne ne peut assumer tout seul la maintenance d'une telle quantité de code.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Antoine J. . Évalué à 1.
Peut-être a-t-il investi dans la société qui développe BK, cela pourrait expliquer pas mal de choses dans cette affaire.
Note: ceci est juste une hypothèse.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, c'est une énorme connerie. C'est dur d'avoir foi en la communauté du libre quand on lit ce genre de truc. Sérieusement, tu t'es dit quoi, "oh lala comme je suis intelligent et que j'ai 'achement bien tout compris aux motivations du vilain Linus, et je vais épater tout le monde avec mes brillantes déductions" ?
Pour disserter pendant des plombes sur les méfaits du propriétaire et dire "y a qu'a faire comme ça c'est bien mieux" à propos de problèmes sur lesquels vous n'avez aucune expérience, y a plein de monde. Pour faire des trucs réellement utiles comme écrire de la doc, faire des traductions, ou corriger des bugs, là y a plus personne.
Et ceux qui répondent qu'ils militent pour linux en en parlant autour d'eux, c'est pareil. Quand on voit le niveau des contribs ici, on comprend pourquoi il est aussi difficile d'avoir de l'aide sur des projets libres.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Antoine J. . Évalué à 1.
Quand je dis que c'est juste un hypothèse, c'est justement pour souligner que ce n'est pas une affirmation. Et je n'ai pas dit ça pour attaquer Linus ou qui que ce soit, j'esperait qu'en faisant cette remarque, de façon un peu provocatrice je te l'accorde, des personnes plus informées que moi pourraient éclairer les lecteurs de cette page sur la plausibilité d'une telle hypothèse.
Tu as choisi de me prêter de mauvaises intentions, libre à toi, mais en criant comme un putois comme tu le fais sans donner le moindre argument tu perds toute crédibilité. La seule chose que je veux que tu me dise c'est pourquoi c'est une énorme connerie, c'est tout, et franchement j'espère que c'est le cas.
Le reste de ton commentaire n'ayant rien à voir avec la choucroute et étant une généralisation grossière, je ne m'étendrait pas d'avantage.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Pour ce qui est de parler du libre, ma crédibilité se porte très bien, merci. Regarde ma homepage ou passe mon nom dans google si tu as besoin de t'en convaincre.
La seule chose que je veux que tu me dise c'est pourquoi c'est une énorme connerie, c'est tout, et franchement j'espère que c'est le cas.
Parce que
- Linus sait très bien que ça ferait un énorme scandale si ça s'apprenait
- Linus ne gagne pas assez pour faire un investissement conséquent pour une boite
- Vu la situation économique du moment, et particulièrement dans la Silicon Valley, si tu as la chance d'avoir du fric à investir, l'envoyer dans une petite boite d'info à l'avenir plus qu'incertain est la dernière des conneries à faire.
[^] # Re: RMS est le responsable = de quoi ?
Posté par Antoine J. . Évalué à 1.
Justement, cela aurait été dommage de ta part de donner comme seul argument «c'est une énorme connerie» alors que tu es en mesure d'en donner de bien meilleurs.
Linus sait très bien que ça ferait un énorme scandale si ça s'apprenait
D'accord, d'ailleurs ça fait déjà un peu scandale sans ça.
Linus ne gagne pas assez pour faire un investissement conséquent pour une boite
Ça j'en sais rien mais je veux bien te croire
Vu la situation économique du moment...
Ce n'était peut-être pas le cas au moment au moment ou Linus a adopté BK pour le noyau linux.
En tout cas merci de ne pas avoir surencheri dans l'engueulade et d'avoir éclairé ma lanterne. Je pense que ma première réflexion (cf. mon premier commentaire), qu'elle soit brillante ou pas a pu venir à l'idée de beaucoup de monde et il est souhaitable que ce point soit éclairci.
Autre petit question:
Quelle est la spécificité du noyau Linux qui rend BK indispensable alors que d'autres gros projets arrivent à s'en passer ? Le plus grand nombre de contributeurs ?
[^] # Re: RMS est le responsable = de quoi ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Un dev dans la Valley gagne dans les $100K/an. Investir dans une boite, ça se fait à coup de millions de $.
Quelle est la spécificité du noyau Linux qui rend BK indispensable alors que d'autres gros projets arrivent à s'en passer ? Le plus grand nombre de contributeurs ?
A vue de nez, je dirais le besoin d'appliquer et surtout retirer très facilement des patchs, ou d'avoir un certains nombre de patches sous le coude et pouvoir dire "je veux appliquer ça ça et ça mais pas ça".
Il n'y a que des gros systèmes de gestion de config (CMVC, ClearCase) qui savent faire ça, mais en contrepartie ils sont lourdingues à utiliser (et très très chers).
[^] # Re: RMS est le responsable = de quoi ?
Posté par #3588 . Évalué à 1.
Ah bon ta « foi en la communauté du LL » est affectée par un post lu sur LinuxFr ? Sérieusement...
Il dit une énorme connerie, oui, l'associer à un mélange de pleins de stéréotypes, c'est pas vraiment nécessaire, il suffit de dire pourquoi c'est une connerie.
« Pour disserter pendant des plombes (...) »
Ca ne sert pas à grand chose de s'adresser à un stéréotype, compilé à partir de ce qui t'arrange. Il y en a aussi qui s'expriment contre le propriétaire et participent au libre. Inutile de les associer à ça (ce que tu fais en caricaturant les posts s'exprimant contre le propriétaire).
[^] # Re: RMS est le responsable = de quoi ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Non, pas que celui-là.
Inutile de les associer à ça (ce que tu fais en caricaturant les posts s'exprimant contre le propriétaire).
Ceux-là ne se sentiront pas concernés de toute façon.
[^] # Re: RMS est le responsable !
Posté par Foxy (site web personnel) . Évalué à 1.
BitKeeper est selon Linus l'outil le plus adapté au developpement du noyau, si il le dit c'eqt qu'il y a des raisons non ?
Effectivement, Linux a refusé CVS car il le trouvait limité et ancien (il n'a pas tort), Subversion car pas assez mûr (pas tort non plus). Mais il existe d'autres solutions, par ex. tous les développeurs du langage Perl utilisent Perforce http://www.perforce.com(...) et s'en portent très bien (même problème que BitKeeper : non libre...).
Comme quelqu'un le disait plus haut, la meilleure solution pour désamorcer le problème, serait de demander aux dev. de Subversion de mettre le turbo et de demander les souhaits de Linus pour que le dev. du kernel passe sur Subversion une fois pour toute.
[^] # Re: RMS est le responsable !
Posté par Anonyme . Évalué à 1.
Ou bien que ceux qui considèrent ces points si importants contribuent financièrement à ce développement. Sont-ils tous des étudiants miséreux ?
[^] # Re: RMS est le responsable !
Posté par #3588 . Évalué à 1.
Il a des raisons personnelles, oui. Le développement du noyau par contre, c'est a priori un travail d'équipe.
[^] # Re: RMS est le responsable !
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Si c'était un travail d'équipe, ça ferait longtemps qu'ils utiliseraient CVS.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Je ne peux pas lire l'article
Posté par imr . Évalué à 1.
cat linux and main > /dev/chiottes
"linux and main"
<avé> le magazine qu'il est pas bien.<avé>
# Re: Bitkeeper, RMS et PLONK.
Posté par Dominique Gallot . Évalué à 1.
Ca fait un super pub pour bitKeeper, c'est peu etres pas libre,
mais point de vue marketing c'est bien fait !
A un tel point, que je vais peu etre l'essayer !
Dominique
[^] # Pareil !
Posté par Samuel Pajilewski . Évalué à 1.
Je ne comprend pas comment certaine personne osent critiquer ce logiciel sans l'avoir utilisé.
C'est completement idiot de bruler un logiciel rien que pour sa license.
ça me rappelle ces categorisations raciales ou religieuses qui permettaient à l'epoque de savoir quelle ou quelle personne etait frequentable. Meme si la comparaison est un peu oséee, j'aimerai que certaines personnes ici reflechissent et aient un esprit critique et constructif sans tomber dans le "C'est pas libre c'est de la merde !"
[^] # Re: Pareil !
Posté par Prosper . Évalué à 1.
[^] # Re: Pareil !
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: Pareil !
Posté par Sismiq . Évalué à 1.
les arguments foireux qui suivent, vaut mieux te les garder.
[^] # Re: Pareil !
Posté par Anonyme . Évalué à 1.
C'est completement idiot de bruler un logiciel rien que pour sa license. »
Qui à parler de « bruler » sinon toi ?
Mais dis moi, après plusieurs années de fréquentation de linuxfr, n'as-tu réllement pas remarqué qu'ici certains considèrent que la liberté en informatique est importante ?
Non, franchement, tu blagues, hein ?
« ça me rappelle ces categorisations raciales ou religieuses qui permettaient à l'epoque de savoir quelle ou quelle personne etait frequentable »
A quelle époque ? Pour toi, des hommes sont équivalents à des logiciels ? Et n'as-t-on pas le droit d'avoir d'avis sur des actes d'autrui ?
[^] # Re: Pareil !
Posté par paparoot . Évalué à 1.
PS: :)
[^] # Re: Pareil !
Posté par #3588 . Évalué à 1.
Pourquoi ? Ca a des implications techniques. Et ca a des conséquences sur les développeurs.
Et puis cette licence fait partie de celles qui sentent bon l'honnêteté, c'est à dire qui expliquent bien sagement que toute nouvelle version de la licence remplace la précédente (même si on utilise toujours l'ancienne version du logiciel), et qu'utiliser le logiciel implique d'accepter cette clause...
« sans tomber dans le "C'est pas libre c'est de la merde !" »
Très juste. On devrait dire : « C'est pas libre, c'est pas libre ».
[^] # Re: Pareil !
Posté par Moby-Dik . Évalué à 1.
au moins l'illuminé nietzschéen était amusant, celui-là est juste casse-bonbons...
# Re: Bitkeeper, RMS et PLONK.
Posté par Thomas Cataldo (site web personnel) . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Sismiq . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: Bitkeeper, RMS et PLONK.
Posté par Arachne . Évalué à 1.
# la légende urbaine de "Linus s'en tape de la GPL"
Posté par oliv . Évalué à 1.
Autant être clair, Linus (et Alan Cox) sont des partisans assez déterminés de la GPL. Leur position sur les symbols GPL_ONLY a été répétée maintes et maintes fois sur la LKML.
Pas plus tard que le 17 de ce mois, Linus a encore sèchement rappelé qu'il n'acceptait pas que l'on distribue des modules non-GPL:
"I will re-iterate my stance on the GPL and kernel modules:
There is NOTHING in the kernel license that allows modules to be non-GPL'd.
The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived."
Je pense que cela prouve l'attachement de Linus à cette license.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la légende urbaine de
Posté par feth . Évalué à 1.
[^] # Re: la légende urbaine de
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: la légende urbaine de
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Si tu as de bugs il faut peut-être regarder du côté de ton chipset (quoi, tu as un via ?? ;).
Alors tu peux les critiquer ces drivers mais moi j'attends encore d'avoir un problème avec.
[^] # Re: la légende urbaine de
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Pauvre naze.
[^] # Re: la légende urbaine de
Posté par kadreg . Évalué à 1.
[^] # Re: la légende urbaine de
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
En gros, fais quelque chose de plus constructif que 'Pauvre naze" ;)
[^] # Re: la légende urbaine de
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
À moins que ce soit l'affichage qui se déforme quand on change de résolution ou la mauvaise qualité de l'image en 2D.
[^] # Re: la légende urbaine de
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Plantage de X ? De toute la machine ? T'es sûr que t'as pas un chipset via ?
fuites de mémoire à 500 Mo par jour
Qu'entends-tu par là ?
Si tu vois beaucoup de mémoire "utilisée" quand tu fais top, c'est l'"agp aperture size". C'est la partie de ram physique utilisée pour stocker les textures qui rentrent pas dans la carte video. Mais c'est pas utilisé vraiment ;)
l'affichage qui se déforme quand on change de résolution
Ca, ça dépend de la fréquence de rafraichissement. Les écrans ne sont capables pour la plupart que de mémoriser un réglage vidéo par fréquence de rafraichissement (exception notable : mon vieux targa 14' mais bon il est tout pourri). Donc on n'y peut rien, à moins d'utiliser des fréquences différentes pour chaque mode vidéo utilisé. Va donc bidouiller ton XF86Config-4 !
la mauvaise qualité de l'image en 2D
Ca, ca dépend du ramdac et non pas du chipset video. Donc c'est pas la faute de nvidia mais celle de l'intégrateur. Et au fait ça n'a rien à voir avec les drivers.
[^] # Re: la légende urbaine de
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Du noyau, et non, je n'ai pas un chipset VIA.
Si tu vois beaucoup de mémoire "utilisée" quand tu fais top, c'est l'"agp aperture size". C'est la partie de ram physique utilisée pour stocker les textures qui rentrent pas dans la carte video. Mais c'est pas utilisé vraiment ;)
Prends-moi pour un con, je ne te dirai rien.
C'est un bug connu, que nvidia n'a jamais pris le temps de corriger, rien à voir avec la taille du top (enfin si, mais quand cette taille atteint le Go et que le noyau commence à tuer des applications au hasard, ça a à voir).
Ca, ça dépend de la fréquence de rafraichissement.
C'est quand même con qu'avec le driver nv ou avec une autre carte vidéo, à la même fréquence, ça ne le fasse pas...
Ca, ca dépend du ramdac et non pas du chipset video. Donc c'est pas la faute de nvidia mais celle de l'intégrateur. Et au fait ça n'a rien à voir avec les drivers.
Faux, ça dépend également des drivers. Et même si la différence n'est pas flagrante, je trouve que l'image est un peu meilleure avec le driver nv.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# linux a 11 ans, momment de changer d'air!
Posté par Sébastien TeRMiToR . Évalué à 1.
Si openbeos ou hurd se developpe je ferais le pas avec plaisir.
mais je fais se pas pour ne jamais revenir en arriere de mes liberté, et de mes idée, il est bien domage que Linus pervertisce les idées qui sont a la base, on ne comtribue pas librement au patrimoine de l'humanité sans faire de politique, oui le locigiel et le travail de FSF, sont des contribuson au patrimoine de l'humanité, ca veut dire que c un cadeau que nous nous fessons a nous meme. c bien plus important que toutes les notion de rentabilitées, quitte a faire bien, j'espere que les devs de linux courageux passerons plutot au port des drivers de linux/bsd vers hurd. c un projet qui du point de vue technique autant que du point de vue des libertées, qui va mille fois plus loin que le noyau linux.
c le moment de tourner la page, de linux vers hurd, et je le pense sincerement!
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Sébastien TeRMiToR . Évalué à 1.
2/ oui hurd et plus simple parce que la gestion des droit et les service ne sont pas dans le noyau, il permet 100 fois plus de develloment surtout lors du pasage a L4/oskit
3/ tu pourrais plus argumenté pour m'expliqué ou je me trompe ?
et corige aussi mon francais s'il te plais, ca peut me servir.
4/ openbeos est aussi une systeme de choix, sait tu qu'il existe au moins 20 systeme libre et plus interesant que linux a pas mal de niveau ?
enfin , argumente mes deux postes plus, ca me servira a mieux te dire ou tu trompe merci!
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
Maintenant, à terme, oui on peut penser que les fonctionnalités du Hurd puissent être utilisées pour donner plus de confort à un utilisateur même néophyte, et à tous les niveaux (hotplug plus simple, meilleur gestion de la sécurité pour éviter les bourdes, sandboxing d'applications pour éviter les risques de trojan/virus, translators en tout genre, ...). Mais ce n'est pas encore là, qu'on ne se trompe pas.
Maintenant, pour répondre au commentaire précédent, j'aimerais qu'on me donne _un_ argument en faveur de Linux et des noyaux monolithiques (à part que Linux est actuellement plus abouti, plus stable, plus rapide, ... oui, c'est vrai, mais ce n'est pas un avantage intrinsèque. J'entends personne dire "Linux 2.4 c'est mieux que Linux 2.5 parce que le 2.5 est instable"...). Pour tous ceux qui vont dire "la rapidité" je vous demande de lire soigneusement les documents qui se trouvent sur http://l4ka.org/publications/(...) avant de répondre, merci :)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
Ca revient en gros à comparer les avantages des l'édition des liens (voire les compilations) statique ou dynamique. On peut plus facilement briser les couches pour faire de l'optimisation quand tout tient d'un bloc, ce qui n'est pas possible dans une architecture montée dynamiquement. Dans ce dernier cas, on est obligé de marquer des frontières entre les modules (ou les objets) et c'est inévitablement couteux en code (donc en poids et en temps).
Donc, le micro-noyau a beau être le plus rapide, ça ne change rien, c'est AMHA un problème d'architecture.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par phq . Évalué à 1.
tu veux dire quoi là ? tu parles d'édition de lien ?
c'est quoi une "architecture montée dynamiquement"?
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
Pour repréciser mon idée (m'enfin je suis un peu HS, je vais tenter de faire court), la tendance actuelle dans le monde du logiciel est le "tout dynamique". On veut pouvoir tout changer pendant l'exécution (en ligne). On gagne ansi en souplesse (cas du Hurd) mais cela induit des surcharges. Par exemple la vérification des communications entre parties du système afin de garantir la stabilité d'un module (considéré alors comme quasi autonome) et donc du système. C'est une chose qui n'est pas (ou moins) utile dans un système monolithique où l'on est forcé de voir les choses dans leur ensemble.
Les termes que j'ai utilisé ou que j'utilise ne sont pas forcément toujours bien appropriés mais j'espère que vous aurez compris. :-/
Désolé de ne pouvoir mettre -1 mais le coeur y est ;)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Houlalala, depuis quand les micro noyaux sont plus rapides ?
Comment ça je n'ai pas lu les doces citées plus haut ? Si, si.
Je vais sur le site en question.
Je lis "The Performance of µ-Kernel-Based Systems" ( http://l4ka.org/publications/files/ukernel-performance.pdf(...) ).
Je vois page 6 et 7 : résultats.
Tout va plus lentement sur L4 que sur Linux (sans exception).
Oui tu as raison c'est un document un peu vieux (1997).
Je prends "Performance of Address-Space Multiplexing on the Pentium" ( http://l4ka.org/publications/files/smallspaces-tr-2002-1.pdf(...) ).
Page 6 : même résultat : linux va plus vite que L4.
Maintenant pour les sceptiques j'ajouterai que les micro-noyaux ne peuvent pas aller plus vite que les systèmes monolithiques, simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
En plus, on a à faire face au problème récurrent des micro-noyaux : toutes les communications doivent se faire par passage de messages d'un serveur à l'autre. Donc si j'utilise mon api noyau préférée, mes données doivent traverser l'espace d'adressage de chacun des serveurs avant d'arriver au matériel, pareil dans l'autre sens. Même si ces communications se font par un segment de mémoire partagée, cela a un coût (imaginez si ce sont des textures ou des commandes OpenGL qui doivent transiter vers la carte vidéo, l'appli va être lente si elles n'arrivent pas rapidement). Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau), mais de toute manière on ne peut pas se permettre d'avoir un bout du noyau qui plante, même si ce n'est q'un serveur de micro noyau (je vois mal les développeurs écrire un serveur de filesystem qui plante toutes les 5 min mais "c'est pas grave on peut le redémarrer le reste plante pas"). C'est le même problème avec les debuggeurs du noyau : il faut faire du bon code ou rien du tout. On ne fait pas marcher un programme (à plus forte raison le noyau, partie critique d'un système) en bidouillant avec un debuggeur.
Et en utilisant le système des modules (inspiré des micro noyau), Linus y a gagné en flexibilité, sans y perdre en rapidité. A mon avis son approche est la bonne, et elle convient au plus grand nombre : ajout/suppression dynamique de modules, dépendances entre ceux-ci etc...
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Donc je ne vois pas de raison technique de passer sur un micro noyau. Par contre je vois l'avantage de rester sur noyau monolithique. L'important est de toute manière que les logiciels open source doivent être portables sur tous types de noyaux et à terme on pourrait imaginer que le choix du noyau devienne une question de préférences personnelles !
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Euuuuuh, dis-moi, tu as quelques notions de génie logiciel ?
Non je demande ça parce que même quelqu'un qui n'en ai pas des tonnes comme moi peut voir que tu es en train de dire une grosse connerie.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Tu m'en veux pourquoi ??
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
En tout cas, tu devrais savoir qu'une architecture véritablement modulaire comme celle du Hurd est beaucoup plus robuste et simple à maintenir qu'une architecture monolithique, et ce au prix de très modestes baisses de performances.
Maintenir Linux stable et fonctionnel avec un tel fatras de code est un véritable tour de force, qui n'a pu être réalisé qu'en rendant de nombreuses parties indépendantes les unes des autres, en un mot en étant modulaire. Et ça influe effectivement sur les performances, on pourrait certainement avoir un Linux plus rapide en se débarrassant de ces interfaces, mais il serait impossible à maintenir.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Donc tu sais qu'il y a un noyau réduit au minimum.
Et que par dessus il y a des quelques "processus" qui tournent et qui effectuent des tâches que fait un noyau monolitique (gestion filesystem par exemple). Ces processus se nomment des serveurs (rien à voir avec un "serveur" dans le sens machine).
Donc quand je parle d'un "un serveur de filesystem qui plante toutes les 5 min" c'est un de ces serveurs-là.
Je n'ai jamais dit qu'un micro noyau n'etait pas stable (au contraire), j'ai dit qu'il n'était pas admissible de tolérer qu'un de ces serveurs plante, même si le reste tenait.
Voila voila
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Bref, tu n'as toujours pas compris qu'un serveur indépendant est infiniment plus facile à déboguer que la même portion de code dans Linux.
Je me cite (très narcissique comme truc) :
Evidemment, un noyau monolithique est plus difficile à mettre au point (pas de droit à l'erreur, sinon on plante tout le noyau)
Sinon à propos de ça :
http://linuxfr.org/comments_reply,10074,142152,1.html(...)
moi tu m'as insulté du premier coup. Donc je trouve que tu te retiens très moyennement.
Pour tes problèmes de driver nvidia (que tu installes et utilise même si tu les trouves nuls), tu ne veux pas les résoudre, la preuve tu ne décris pas précisement tes problèmes/ton matos. Ou peut-être ces problèmes n'existent pas (et il s'agit d'un FUD aussi primaire que ceux de microsoft).
Je t'ai expliqué ce qu'était un serveur, mais tu ne veux pas apprendre. Exit donc la discussion avec toi.
Bref prends exemple sur Gaël Le mignot (plus bas) qui m'oppose des arguments valables au lieu d'insulter sans arguments.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Anonyme . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . Évalué à 1.
Ensuite, je te rappelle que ce ne sont pas que des parties essentielles qui se trouvent dans le noyau. Par exemple, le montage NFS du pauvre petit utilisateur à qui on a permis de se monter une partoche via NFS (déjà qu'il a fallu qu'il demande à root, parce qu'évidemment seul root peut faire ça, et à raison en ce qui concerne les systèmes à noyau monolithique[1]) doit-il permettre de faire tomber l'ensemble du système ? Je ne le pense *vraiment* pas.
Même chose pour un serveur essentiel pour fournir les tâches imparties à la box, mais pas essentiel au système, comme par exemple, la pile TCP/IP. Je sais pas pour vous, mais j'en ai quand même vu crasher après un slashdottage. D'ailleurs, c'est bien la pile TCP/IP de Linux 2.2.14, qui est la base de pfinet actuellement (en cours de redesign) qui avait crashé plusieurs fois lors d'un /.age d'un serveur web sous GNU/Hurd (et c'était, on l'a découvert ensuite, bien lié à un bug de cette pile, qui a été rapporté par la suite). La différence étant que sur un système basé sur un noyau monolithique, ça veut dire plantage général et redémarrage (donc downtime assez important), alors que sous GNU/Hurd, ça veut dire pile TCP/IP qui crashe et qui est redémarrée automatiquement dans la seconde qui suit. (donc, des conséquences mais bien moins importantes)
Pour prendre l'analogie avec la sécurité, le Hurd ne prétend pas résoudre les problèmes de sécurité. Il prétend fournir des mécanismes de sécurité qui permettent aux développeurs de minimiser les conséquences de tels problèmes[2]. De même, il ne prétend pas résoudre tous les problèmes de stabilité. Mais, partant du principe qu'a priori, un programme a toujours des bugs potentiels, surtout lorsqu'il s'agit de programmes relativement complexes comme ceux s'occupent d'un système de fichier, il prétend minimiser les conséquences de tels plantages.
Enfin, pour avoir suivi le développement de Linux depuis assez longtemps, et avoir eu moi-même quelques expériences avec, je sais que les bugs sont loin d'être tout le temps dans la partie où ils apparaissent. S'il est vrai qu'il a été nécessaire de « cloisonner » Linux, comme le disait JJB (encore un pote à JJB!), créer un énorme logiciel qui contient des tas de parties différentes amène naturellement plus de risques de se planter, en ne connaissant pas bien ce que fait telle autre partie, en se gourrant sur un lock, ou que sais-je. De plus, une inversion de paramètres est vite arrivé, et si les changement dans les interfaces externes de Linux sont déjà fréquents, les changements dans les interfaces internes sont plus que monnaie courante, causant donc de nouveaux problèmes potentiels. Comme le disait JJB, si Linux tient, c'est par le plus grand des miracles, et quelques fois ça fait quand même badaboom. Entendez-moi bien, je ne critique pas non plus les « irresponsables » développeurs de Linux, etc. : une grande partie du miracle grâce auxquels ces sources tiennent s'appelle Alan Cox, Linus Torvalds, Rik Van Riel, Harald Welte, et autres personnes extrêmement douées du genre. Mais je persiste à croire que si ces ressources étaient mises à disposition d'un projet ne posant pas ces problèmes de bases, elles seraient mieux utilisées. (NB: et Harald est pas très loin de penser la même chose :-)
Au fait, de façon évidente, si ces « processus » (processi? processus? (4ème F/M) processa? (3ème neutre) (latin roxor (lisp aussi))) sont appelés serveurs, c'est par analogie avec le fameux modèle client-serveur (qui a dit buzzword?). Je tiens également à revenir sur la composition d'un noyau monolithique. En tant que fourre-tout officiel de tout ce qui n'est pas « bibliothéquisifiable » (j'adore ce mot. pas vous? ah bon[3]), il n'est pas évident de définir ce qu'il contient dans un système « Unix » (non, nous ne reprendrons pas le troll, j'ai déjà donné mon point de vue). Mais il ne contient certainement pas que des parties essentielles au système: il contiendrait plutôt tout ce qui doit être commun à toutes les applications et peut poser un quelconque de sécurité, ou que sais-je. Plus récemment, la manie a été d'intégrer dans le noyau tout ce qui peut se rapprocher du « bas-niveau » (PPPoE, etc.). Il est donc loin d'autant moins évident de garantir la stabilité de ces parties non-essentielles, et il me semble dément qu'ils puissent faire tomber l'ensemble du système. Enfin, vous me direz, ça ne s'applique pas forcément aux serveurs de production. Mais je crois que la stabilité n'intéresse pas que ces premiers.
[1]: mon expérience de ce genre d'explications m'a montré que ce point là était en général un des moins bien compris, et que la question « Et pourquoi on pourrait pas monter des trucs en user sur mon Unix? Moi je peux avec users dans le fstab ! ». Répondons directement. Oui, on le peut: via le setuid root. Je pense que rien que l'invocation de cette fonctionnalité devrait faire frémir tous ceux qui se sont un jour préoccupé de sécurité. :-)
Sous Unix, si on autorise tous les utilisateurs à effectuer l'appel système `mount', rien ne les empêche de créer une image d'un système de fichiers reconnu par le noyau contenant des programmes « setuid root » (justement!) qui seraient alors intégrés tels quels dans le VFS, sans distinction d'utilisateur avec les autres partitions (il n'y a pas ce genre de notions avec Unix), permettant ainsi à n'importe quel utilisateur de devenir root. Sous GNU/Hurd en revanche, le « serveur » s'occupant du système de fichier (on parle de « traducteur » ou « translator » pour le Hurd, en raison de ses spécificités) est une application _comme_ _les_ _autres_, qui tourne en mode utilisateur avec les droits de l'utilisateur qui l'a lancé. Il ne peut donc *rien* faire de plus que cet utilisateur. Tiré d'un document écrit par Marc, Kilobug et moi-même:
(mmenal@drizzt, 25) ~ $ sudo chown mmenal /dev/hd0s3
(mmenal@drizzt, 26) ~ $ settrans -cgap foo /hurd/ext2fs -r /dev/hd0s3
(mmenal@drizzt, 27) ~ $ cd foo/bin
(mmenal@drizzt, 28) ~/foo/bin $ ls -l ping
-rwsr-xr-x 1 root root 15368 May 23 18:27 ping
(mmenal@drizzt, 29) ~/foo/bin $ ./ping hurdfr.org
bash: ./ping: Operation not permitted
(jvous jure, l'idée de pinger hurdfr.org était de KB :-p)
Même si c'est franchement hors-sujet, j'espère que cela aura su répondre aux interrogations de certains. (et puis même si vous vous posiez pas la question, vous savez maintenant! :-)
[2]: Je tiens à citer Wolfgang Jährling, qui commençait son (excellente) conférence sur les mécanismes d'authentification du Hurd, dont un court résumé est disponible sur http://www.gnu.org/software/hurd/auth.html(...) , par un retentissant « security is just a bad hack ». En effet, n'oublions pas que la vraie réponse à la sécurité est de rendre les gens bons, de telle façon que tout le monde reporte les problèmes de sécurité sans jamais les utiliser à des fins malhonnêtes - et que personne n'ait même de buts qui ne soient pas louables! Mais malheureusement, cette tâche est quelque peu difficile à accomplir en écrivant des logiciels. Nous sommes donc condamnés à se limiter à ce bad hack qu'est la « sécurité » :-)
[3]: j'espère que les amateurs auront reconnu une fine allusion à Renaud, et pourront donc me dire de quelle chanson je parle :-p
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
Je pensait plutôt à la comparaison L4 / Mach 3. J'espère que tu n'avais pas compris L4 / Linux...
Page 6 : même résultat : linux va plus vite que L4
Ah ! Zut :). Je ne me suis jamais lancé dans ce genre de comparaisons pour plusieurs raisons. Premièrement je n'ai jamais fait le test (j'ai bien parlé en "théorie"!). Ensuite, parce qu'il est difficile de comparer ces deux choses. Linux est poussé par des centaines de développeurs et L4 n'a pas pour vocation de couvrir autant de choses que Linux (par exemple l'intégration d'une pile TCP/IP).
Pour le reste, je suis en grande partie d'accord avec toi, mais je préciserait qu'il s'agit bien du problème des architectures à micro-noyau face aux architectures monolithiques.
Et voici une raison technique en faveur des architectures à base de micro-noyau : un gain en souplesse. Mais tu as tout à fait raison dans ta conclusion, le principal est de pouvoir choisir...
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par ghent . Évalué à 1.
Leurs conclusions ont ete simple, la version en assembleur bien que plus rapide, la version en C lui etait superieur car etait bien plus lisible, et maintenable.
Le debat entre noyaux monolithique/micro-noyau est assez semblable.
Les gains de possibilites avec un micro-noyau est largement superieur a un noyau monolithique (modularite extreme, meilleure securite, meilleure portabilite, et j'en passe). Et la perte de performance se retrecie de plus en plus (voir les differences entre un mach3 et un l4).
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
T'as rien compris à l'article. Il compare L4Linux et Linux. Bien évidemment un port de Linux au-dessus de L4 à coup de glue-code est plus lent que Linux en natif. Le but de cet article n'est pas de comparer L4 et Linux (ce qui n'a pas de sens) mais de comparer L4 et Mach dans le cadre de L4Linux et de MkLinux.
De plus le L4Linux testé est basé sur une vieille version de L4 qui est loin d'implémenter toutes les optimisations possibles.
"Performance of Address-Space Multiplexing on the Pentium"
Idem, cet article compare L4Linux et Linux, avec des applications utilisant les sémantiques POSIX. Pas un système à base de L4 utilisant les sémantiques L4 et des programmes utilisant de l'IPC L4.
simplement parce qu'un système monolithique utilise moins de protections mémoire qu'un système micro-noyau.
et ?
Sur un noyau monolithique, un appel et le noyau a récupéré toutes les données dans son espace d'adressage et ca va direct au matos.
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
A propos de la sécurité, il existe à l'heure actuelle des patchs comme grsecurity qui font plus que leur travail, avec les ACL par exemple.
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protection.pdf(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
quoi, concrètement ?
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache). De toute manière quand je constate la subtilité des optimisations des performances du noyau, je pense que le raisonnement sur le papier n'apporte pas grand chose...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique". Fin de la discussion pour l'instant. J'utilise des guillemets pour monolithique parce que le système des modules ainsi que les différentes couches d'abstraction des noyaux modernes rendent ceux-ci beaucoup plus faciles à développer et je ne suis pas sûr que les micro-noyaux possèdent toujours de si nombreux avantages.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
Tu es tombé dans le piège, vu qu'un RPC est plus rapide qu'un appel système.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
Qu'est-ce que tu veux que je dise de plus ? Allez, fais un petit effort, et après on en reparlera (et lire, c'est lire, pas regarder les tableaux et les graphes sans lire le reste...)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
euh... tu m'expliques là ? j'suis pas le seul à pas comprendre ce que tu entends par là... Par définition, le noyau c'est ce qui s'exécute en mode noyau....
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système
Parce que le noyau et le serveur spécialisé étant tous les deux plus simples et plus compacts, l'empreinte sur le cache, les problèmes de pile, ... sont réduits. Avoir un gros noyau oblige à compliquer le code à base de locks, ... qui coûtent chers en terme de performance.
De plus, les serveurs sont beaucoup plus facilement préemptibles et multithreadés que le code noyau, ce qui donne aussi un gain de performances, surtout sur les machines multi-processeurs.
Mais surtout, le plus important ce n'est pas le gain sur le RPC ou le syscall lui-même, ce sont toutes les autres optimisations qui sont possibles avec un système à base de micro-noyau, comme le 0-copy (cf mon post plus haut), la possibilité pour les programmes de gérer eux-mêmes leur mémoire virtuelle (ou au moins d'utiliser une VM qui leur convient, puisqu'il n'y a pas de VM optimale), ou bien l'optimisation des IPCs qui existent déjà. Trouve moi un seul noyau monolithique où tu peux choisir la VM et le scheduler que tu veux utiliser ? Sur un système à base de micro-noyaux, tu peux même avoir plusieurs VM et plusieurs schedulers pour des applications différentes. Et là, le gain de perf peut être énorme.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
Quand au reste, j'abandonne. Je t'avoue que lire une traduction des arguments des concepteurs de L4 sur linuxfr ne m'intéresse que moyennement. Comme je te le disais plus tôt, je ne connais pas beaucoup de chercheurs qui critiquent leur propre travail. Donc, on va dire que tu as gagné et que je viendrais m'excuser piteusement dans 5 ans quand les micro-noyaux domineront le monde.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . Évalué à 1.
Il sait parfaitement de quoi il parle. Et ses goûts quant aux langages n'ont rien à voir avec ses connaissances techniques, qui concernant les micro-noyaux sont plus importantes que n'importe qui ici (pitet sauf moi, parce que c'est quand même moi qui l'ai convaincu ..). Les attaques personnelles de ce type sont plus que malsaines, elles m'écoeurent profondément.
J'ai relu tous les posts de Gaël ici (deux avis valent mieux qu'un), et je peux t'assurer qu'il n'est pas le seul qui aurait répondu comme ça. Peut-être effectivement est-ce dû à une mauvaise expression de ta part. Pour autant que je sache,
J'ai lu les docs L4 (avant de poster). Pour faire un IPC, on passe le thread en mode noyau (j'ai pas dit DANS LE NOYAU, j'ai dit en MODE NOYAU), exactement comme pour faire un appel système.
est un non-sens complet. On ne passe pas le thread en mode noyau. D'ailleurs, une définition correcte et assez précise du sens noyau, qui est la mienne (et ensuite celle de Kilobug), est qu'il consiste en tout ce qui tourne en mode « noyau ». On passe effectivement en mode noyau (instruction iret), mais tu changes pas les permissions d'un thread comme ça, hop. Il s'agit d'un CALL/SYSENTER (« inter-privilege-level far call », disent les docs Intel), puis d'un IRET/SYSEXIT. Effectivement, l'IPC entre tâches différentes se fait via un appel système avec L4 (et avec tout micro-noyau, en tous cas sur les architectures récentes et que je connais, avec MMU), il y'a donc le coût du changement de « privilege level » (relativement important sur un PIV, il faut l'avouer).
comment un IPC peut coûter moins cher qu'un appel système alors que l'IPC ajoute des instructions par rapport à l'appel système (on est d'accord, il y a très peu d'instructions en plus).
Si tu compares le nombre d'instructions, tu as en théorie raison. Cependant, ce que Kilobug t'a fait remarquer est que les mêmes instructions, les mêmes accès, faits dans des contextes différents n'a pas *du tout* le même poids. Le noyau est un énorme programme extrêmement complexe, où on doit lock'er de partout, etc. Le poids de ces locks est déjà un poids supplémentaire. L'empreinte sur le cache, étant donné que l'application est plus grosse, fait plus de choses, etc., est aussi considérablement plus importante. D'où encore pertes de performance. Or, il s'agit là d'un des facteurs *essentiels* vis-à-vis de ces dites performances. (Ceci dit, quand il s'agit du Hurd, on ne peut pas vraiment comparer, puisque le open() ne fait rien de comparable à ce que fait le open() de Linux.)
N'oublie pas qu'il s'agit de performances. On ne peut pas avoir une comparaison directe, fiable à 100%, manichéenne quand il s'agit de performances. Tel critère peut représenter une perte de performances, mais tel autre peut également, selon la façon dont s'est fait, selon les cas, etc., le compenser, voire plus. C'est pour ces raisons que Gaël a cité un certains nombres de choses qui peuvent te paraitre hors-sujet, mais qui pourtant ont un rôle prédominant quant aux performances. J'en profite d'ailleurs pour répondre à bknight, qui disait:
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
La chose me paraît impossible. On ne peut pas faire des benchmarks sur des théories. Je peux te trouver des systèmes à base de micro-noyaux plus rapides que d'autres à base de noyaux monolithiques, et vice-versa. Il n'y a pas de bench parfait: même un bench du même code tournant sur un micro-noyau et sur un noyau monolithique serait absurde, parce que le code ne serait pas optimisé pour l'un ou l'autre (et d'ailleurs, par nature plutôt pour le second, puisqu'il s'agirait d'un serveur monolithique). C'est pour cela qu'il faut prendre les bench de L4Linux avec des pincettes. Et se souvenir que dans biens des cas MkLinux - « pendant » de L4Linux sur Mach - est bien souvent (tout le temps?) moins performant que le Hurd sur L4.
Les performances sont à traiter au cas par cas. Il semble logique, dans le cas d'un open(), qu'au final le coût soit à peu près le même: les pertes toutes relatives dues à l'IPC sont compensées par une moindre pollution des lignes de cache, etc. En revanche, dans le cas d'un write () où d'un appel plus complexe, l'utilisation de µk peut permettre d'utiliser des techniques plus performantes. Mais le µk en lui-même ne rendra pas les choses plus rapides, encore faut-il l'utiliser. C'est aussi pour ça que le Hurd est nouveau: certes les systèmes à base de micro-noyau ne sont pas nouveaux, mais aucun, sorti du domaine de la recherche, n'en tirait parti comme le Hurd, à ma connaissance, et encore moins comme il le fera quand le port sur L4 sera terminé.
Une petite remarque de forme. C'est gentil de toujours faire référence aux papiers sur L4, mais bon, je ne connais pas beaucoup de chercheurs qui crachent dans leur propre soupe.
Effectivement, cela est vrai. Mais il n'empêche que ce qu'il présente, ce sont avant tout des *faits*. Et à moins que tu me montres qu'ils sont faux, infondés, ou que sais-je, ce sont la base d'arguments valides. De même que je ne connais pas de papiers qui proposent des contre-arguments à L4, ou qui montrent que c'est faux, que c'est forcément plus lent avec L4. Le seul qui m'ait dit ça, c'est Rik (Van Riel), et bizarrement, il a toujours quelque chose de très urgent à faire dès qu'il s'agit de me montrer en quoi.
Mais qu'est-ce que tu racontes ? Comment fais tu un ipc sûr sans passer en mode noyau ?
Là, je voudrais nuancer légèrement. Tu ne peux pas faire d'IPC sûr sans passer par le mode noyau, effectivement, si on garde à l'esprit que IPC = « Inter Process Task ». En revanche, tu peux faire des RPCs locales, i.e., entre threads d'un même groupe, d'une même tâche, sans passer par le mode noyau. (et oui, c'est utile, je vous prie de se referrer au début et à l'ensemble de http://www.l4ka.org/publications/files/lazy-process-switching.ps(...) (oh! mon Dieu, encore une référence aux docs L4! Mais ce gars n'y connait rien! sauf que ce gars échange avec Horst Wenske (mais malheureusement pas avec le regretté Jochen Liedtke :-( ))). Ça s'appelle LIPC, et ça fait partie des services qu'un noyau et qu'un système d'exploitations peuvent fournir pour permettre d'avoir un ensemble plus rapide.
Euh, c'est une question piège ? Disons, un RPC ? Le problème, c'est que sauf erreur de ma part, ça fait un changement de contexte et que ça coute des ressources (par exemple tu dois avoir un risque de niquer le cache).
<tribune>Pas du tout, efface.</tribune> Cela fait un changement de contexte dans quelques cas très particuliers. Enfin, soyons clair. Cela fait un changement de contexte dans tous les cas: on change de tâche, on modifie deux/trois trucs. Mais c'est une hyperbole que dire que c'est peu coûteux. De plus, le cache primaire est indexé physiquement, donc cela ne coûte encore une fois que quelques cycles. Les coûts sont donc liés à, comme tu le dis, au « cache » (« niquer le cache », expression qui me plait décidément beaucoup). Plus exactement, au TLB. Liedtke décrit des mécanismes pour PowerPC et pour x86. L'idée pour x86 est assez simple: sur les 4GO d'espaces d'adressage, les tâches qui ne requièrent pas un espace d'adressage phénoménal (i.e., <500MB, si mes souvenirs sont bons, mais cela a pu changer et est peu ou pas décrit par Intel), donc la vaste majorité des tâches (en fait, toutes sauf 1 ou 2 sur la plupart des systèmes), n'ont pas accès aux 3GO d'address space normaux, mais seulement à une petite partie, de 500MB. Or il est tout à fait possible de multiplexer, de partager ces petits espaces d'adressages entre les gros, de 4GO. Dans la plupart des cas, un « changement de contexte » se fait entre deux tâches occupant des petits espaces d'adressage. Il n'y a donc pas de réel changement de page table, donc pas de TLB flush, donc pas un « réel » changement de contextes. En revanche, il est vrai que dans les cas où une petite tâche va faire une RPC à une tâche disposant d'un gros espace d'adressage n'étant pas celui en cours, ou encore dans le cas de communication entre « grosses » tâches, un TLB flush va être nécessité. Mais l'économie par rapport au context switch sur Linux, ou plein d'autres systèmes - Windows NT, pour autant que je sache - est monstrueuse. Pour PowerPC, c'est encore plus simple, et pour le coup il n'y a plus du tout de TLB flush, puisqu'il est très facile d'avoir un address space de 2^52 bytes, et donc d'« émuler » une TLB taggée sans ses inconvénients.
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Ça ne veut pas dire grand chose, tu t'en rends compte ? GNU/Hurd est probablement plus rapide que certains systèmes d'exploitation basés sur des noyaux monolithiques. Qu'en revanche il n'existe pas de systèmes d'exploitation aussi versatile que GNU/Linux basé sur un micro-noyau qui soit aussi rapide que ce dernier, je te l'accorde. Mais encore une fois, ça ne constitue pas du tout une preuve. Il n'existe pas à ma connaissance de raisons pour lesquelles ça ne serait pas possible, et il existe même des raisons de penser qu'on pourrait faire un système d'exploitation à base de micro-noyau plus rapide. Si je n'en étais pas persuadé, je ne travaillerais pas sur le port du Hurd sur L4.
Pour finir, j'aimerais revenir sur le commentaire auquel je réponds directement. Je ne sais pas ce que tu essayais de prouver en rappelant les positions de Kilobug sur un tout autre sujet, à savoir le C vs. le C++. Je connais bien Kilobug, mieux que quiconque ici (et que la plupart ailleurs), et je suis d'ailleurs d'accord avec lui sur ce point: le C++ n'est pas un langage que j'aime, et je le trouve absolument dégueulasse. Est-ce que pour autant on doit m'enlever le droit de m'exprimer ? Est-ce que ça m'enlève tout crédit pour parler d'autre chose, et même de ça ? D'autant plus que Kilobug fait du C++ tous les jours (ach, 3j/sem maintenant), et que donc il ne parle pas sans savoir. Il est même probablement plus renseigné dessus que beaucoup de monde ici, puisqu'il lit énormément et est de bonne volonté à ce sujet. Bref, je trouve ces méthodes digne des plus grands boulets, des plus infâmes, que l'on peut malheureusement rencontrer sur DLFP. Plus que de casser la crédibilité de Kilobug, c'est la tienne que tu viens de casser à mes yeux et aux yeux de nombre d'autres.
Ceci dit, le débat purement technique sur les micro-noyaux m'intéresse, et je pense être pas trop mal renseigné sur le sujet. Donc, puisque cette news n'est plus depuis longtemps en page principale, je vous invite, tous, et en particulier toi et bknight (et puis jjb<, s'il veut :-), à continuer la discussion sur une ML, et même devant une guinness si vous habitez dans la région parisienne (oui, oui, un lait fraise pour kilobug :-).
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
Sinon, commençons pas la fin. Si je fais une attaque pitoyable contre kilobug, c'est parce que si j'avais su dès le début que c'était kilobug, je n'aurais pas pris le temps de discuter pour une raison très simple : j'ai pu constater sa terrible mauvaise foi dans une très longue discussion sur C vs C++, contre divers intervenants. J'avoue que discuter avec quelqu'un qui fait de tel post, ça ne m'intéresse pas trop, même si je n'ai rien à reprocher de la sorte (enfin, pas trop) sur ses posts concernant les µ noyaux. Tu me diras que c'est très con, comme mon commentaire sur "il ne sait pas de quoi il parle". Et tu auras raison.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
D'autre part, tu aurais pu te passer du cours sur le flush de la TLB, j'ai lu "Performance of Address-Space Multiplexing on the Pentium", ainsi que d'ailleurs la plupart des publications sur L4. Donc, oui, mes phrases sur le mode noyau était un peu délirante, mais je savais quand même de quoi je parlais. J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Manuel Menal . Évalué à 1.
Quant au cours sur le TLB flush etc. (qui n'en était pas un, c'était extrêmement bref et récapiulatif), c'était simplement pour remettre les choses au clair, avec toi et les autres lecteurs ici. Et bien s'assurer qu'on parle de la même chose: tu emploies parfois des termes assez bizarres, et j'avoue que j'ai parfois été tenté d'aller chercher le de-yoda-ifier.
J'aime d'ailleurs cet article car il indique explicitement que la technique en question peut être portée sous Linux monolithique et permet d'avoir les mêmes performances. Comme par hasard, kilobug et toi ne mentionnez pas ce fait. Mauvaise foi ?
Non. C'est d'ailleurs assez étrange, parce que nous en parlions justement y'a pas plus d'une heure (devant une pizza :-p) avec Kilobug, et nous ne savions pourquoi l'astuce du 2^52 sur PPC n'était pas utilisée par Linux sur cette architecture, car elle est très simple à réaliser. Mais, je ne pensais pas, et je ne pense toujours pas, que ça ait eu un intérêt dans l'optique de notre conversation et pour ce que je voulais montrer.
Effectivement les noyaux monolithiques pourraient l'utiliser, mais ça n'empêche que les systèmes à base de micro-noyaux peuvent ne pas être moins performant, notamment grâce à cette technique. Attention à ne pas rentrer dans la simplification schématique: 1) les systèmes µk-based sont moins rapides avant 2) on améliore les performances des deux => les systèmes µk-based sont toujours moins rapides comparativement. Si par exemple les systèmes µk-based étaient simplement plus lents à cause des cont-sw, et qu'on supprimait les cont-sw, ça mettrait les deux systèmes sur un pied d'égalité a priori. Pas plus.
Quelques explications sur mon délire de noyau. Quand je parle de passer en mode noyau, je veux bien sûr parler de changement de privilège. Quand j'ai dit "dans le noyau", je voulais dire un accès à un des services externes au noyau (dans le cadre des µ-noyaux). Oui, je sais, ça peut paraître délirant, mais bon, je ne suis pas toujours très clair.
Je ne sais pas si c'est la fatigue ou la guinness, mais je ne comprends toujours pas mieux ce que tu veux dire, et tu as fait lamentablement segfaulter mon de-yoda-ifier.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre)
Effectivement, je n'aime pas faire de multiples commentaires juste pour le plaisir, je préfère tout grouper. Peut-être à tort, puisque ça a l'air d'en effrayer certains. Il est vrai que mon style n'est de loin pas des meilleurs.
sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
Uh? C'est quand même un peu évident. Plus tu as une grosse application avec plein de trucs qui s'effectuent en même temps, s'agissant en plus d'un noyau avec des interrupt handlers, des possibilités d'être reveillé d'un peu partout, et tout ça, plus tu vas avoir besoin de locks, et de complications pour éviter que toutes les pièces se marchent dessus. Tous ces locks ne sont pas justifiés lorsqu'il s'agit de tâches différentes. (bien sûr, il y'a toujours besoin de locks, sur des container et autres, mais ça n'a rien à voir, et ce ne sont pas des big global locks manipulés plus que fréquemment)
Pour les longs commentaires, euh, je les tape dans mon galeon, ou dans mon emacs puis je les copie dans mon galeon. GNU Emacs + Galeon, le couple gagnant ! ;P
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
Enfin, tu réponds à des choses qui ne sont pas de moi (genre bench neutre) sans expliquer pourquoi il y aurait moins de lock dans un système à µ-noyaux que dans un système monolithique.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
Grâce au multiplexage d'espace d'addressage (expliqué en détail dans les docs L4), justement, on peut faire de l'IPC sans réel changement de contexte (sans TLB flush par exemple).
Pour de l'IPC entre deux processus différents, oui, on est obligé de passer par le noyau. Par contre, le code exécuté dans le noyau pour transmettre l'IPC est si court et si simple, qu'il s'exécute très rapidement, et surtout sans polluer les lignes de cache. Le coût total d'un RPC L4 est donc inférieur à celui d'un appel système sur Linux.
De plus, dés qu'on veut un peu plus de fiabilité, de tolérance de panne et de souplesse, on ne met plus la totalité du code dans le noyau (comme le serveur X, par exemple, qui est en user-space). Donc là, on se retrouve à faire de l'IPC entre le client et X, avec un noyau qui n'est pas du tout prévu pour, et donc on a une perte de performances beaucoup plus importante. La même chose s'applique, par exemple, à une compilation en -pipe, ...
Tout ça pour dire que aujourd'hui je pense qu'aucun système à micro-noyau n'est aussi performant qu'un système "monolithique".
Je ne l'ai jamais nié. L4 existe, est extrêment rapide, mais il n'existe pas encore de système complet basé sur L4 aussi versatile qu'un GNU/Linux (il y'a bien des OS basés sur L4, mais uniquement pour des domaines très pointus et précis pour l'instant).
Quant aux modules, ça n'a absolument rien à voir avec ce que peut faire un système à base de micro-noyau.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
Par contre, je suis d'accord avec le fait qu'un excellent mécanisme d'IPC est un bien, mais bon l'enfonçage de porte ouverte, c'est pas trop mon truc. Je suis aussi tout à fait d'accord, un micro-noyau permet de faire plus de choses qu'un noyau monolithique. Les modules simplifient seulement le développement.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
J'attendais ce contre argument. Mais justement, au début de l'article, l'auteur mesure l'overhead de l4linux à 5%. Et la différence de perf linux/micro noyau est de plus de 5%. Donc...
Ça et le reste du paragraphe montre que tu n'as rien compris à la philosophie des micro-noyau. Dans un système à base de micro-noyau 'idéal', le serveur d'affichage 'mappe' la mémoire vidéo dans son espace d'addressage à lui; le client qui veut afficher des textures fait un IPC vers le serveur d'affichage en passant les données à placer via des flex-pages (pour prendre la sémantique L4). Le serveur d'affichage fait la copie et rend la main. Coût total: un RPC. Aucune copie superflue. Tu perds quoi, concrètement ?
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
Prenons un autre exemple: une écriture sur le disque. Sur un noyau monolithique, tu appelles write(), qui copie les données dans le buffer du driver et ensuite les écrit. Sur un système à base de micro-noyau, tu passes tes flex-page contenant les données (donc, juste un IPC faisant un 'grant' sur les pages, aucune copie) au driver, qui 'pin' les pages en mémoire (pour éviter qu'elles ne soient swappées) et démarre le transfert DMA. Total: aucune copie n'a été réalisée.
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Tu peux comparer ça à ce qui est présenté dans http://l4ka.org/publications/files/os-protectio(...) ? On joue pas dans la même catégorie là... Avec tous tes ACLs et des patchs grsecurity, login, sshd et *ftpd tournent toujours en root sur ta machine, je te signale.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). Mais je préfère la rapidité. Les mechanismes de sécurité de Linux me suffisent largement. Et pour l'instant ce genre de choses j'attends de le voir tourner.
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Voila, merci de m'avoir fait me replonger dans les micro noyaux, ca fait un certain temps que j'y avais pas regardé et ça a l'air d'évoluer en bien.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
Donc quoi ? Linux n'est pas adapté à être mis en monoserveur au-dessus d'un micro-noyau. C'est un fait, et c'est évident. Mais cela ne permet donc pas de juger des performances possibles pour un système versatile utilisant L4. En revanche, on peut considérer qu'étant donné que même dans ce cas suboptimal, les différences sont assez minimes à l'utilisation, les performances d'un tel système *conçu* pour les µk et tirant parti de L4 (notamment des LIPC, etc.) pourraient être excellentes.
J'ai besoin d'un appel au serveur d'affichage à chaque fois que j'affiche un truc. A comparer au dga, seule méthode qui me permet de jouer des divx sans saccades sur ma machine.
1/ implémenter un protocole pour demander au serveur d'affichage de mapper la mémoire vidéo dans la mémoire de l'appli c'est parfaitement possible
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Oui, mais qu'est-ce qui m'empêche d'implanter la même optimisation sur noyau monolithique ?
Fais-le, et on verra. Le kernel space et l'user space sont deux espaces distincts. Faire une opération de 'grant' ou de 'map' entre deux programmes en espace utilisateur (le client et le driver) c'est la base de l'IPC de L4, c'est extrêment simple. Permettre au driver de taper directement dans la mémoire de l'application, sachant que le driver fonctionne de manière asynchrone et que l'appel write() peut être non-bloquant est quelque chose de beaucoup plus complexe. Presque infaisable.
Effectivement, on a un avantage au niveau de la securité (que je n'ai pas nié). et un peu avant Donc je ne vois pas de raison technique de passer sur un micro noyau.
Heu... contradiction là ?
Et il reste sur les processeurs x86 deux niveaux de privilège d'exécution non utilisés qui pourraient être utilisés pour ça.
Là, j'aimerais bien savoir comment.
Mais je préfère la rapidité.
Mais tu n'as pas plus de rapidité !
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Stephane Marchesin (site web personnel) . Évalué à 1.
Pour l'instant ce n'est pas le cas. Je surveillerai néanmoins tout ça de plus près maintenant ;)
2/ le DGA sous GNU/Linux, il faut avoir les droits roots. Avec un protocole bien conçu, il est possible de faire sur un multi-serveur sans avoir de droit root (juste un token "dga")
Ca peut se faire aussi sous linux, mais ça n'existe pas encore, c'est en développement :))
Fais-le, et on verra.
Voici la méthode que je propose :
le processus fait appel à une fonction write() sur une page
write() marque la page en question non writable(et on la locke en ram) (ou encore mieux, utiliser un genre de copy on write !)
...
l'appel d'écriture asynchrone se fait
on marque la page writable à nouveau (et on la delocke) (ou on la détruit si on a fait le pseudo copy on write et qu'on a fait une copie entre temps)
Si entre temps le processus a tenté une écriture sur cette page on peut
l'intercepter et l'endormir. Ou si on a fait le pseudo copy on write il peut continuer, et on ne procède à la copie que si c'est nécessaire.
T'en pense quoi ?? Ca m'a l'air pas mal, mais il doit y avoir un problème sinon tous les noyaux monolithiques feraient comme ça.
Là, j'aimerais bien savoir comment.
L'idée est d'utiliser les niveaux de privilèges non utilisés sur x86 de la manière suivante :
On rajoute un privilege level de 1 (et si on veut de 2 aussi) contenant les fonctions autorisées avec moins de droits (celles que pourront lancer un programme qui a besoin de droits mais qui ne devrait pas être root). Au lancement d'un proc on le marque en fonction de son "niveau de cpl sous-jacent" (hum, j'espère que tu vois ce que je veux dire, c'est mal expliqué). Lorsqu'on fait un appel système, il est opéré par le cpl sous jacent correspondant si le programme a le droit de le faire, sinon... Et les cpl de 1 et 2 ne touchent pas à 0, donc ce qu'on voulait faire est accompli.
Problème : toutes les architectures n'ont pas 4 niveaux de privilèges :(
Le reste du débat micro noyau/monolithique m'apparaît de plus en plus comme une question de point de vue personnel. J'attends toujours un bench complètement neutre sur la chose.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
Beaucoup d'autres optimisations peuvent être réalisées (0-copy, multiplexage d'espaces d'addressage) de manière beaucoup plus simple et efficaces sur des systèmes à base de micro-noyau. Lis un peu les docs dont je te parlais avant de parler.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Sébastien TeRMiToR . Évalué à 1.
la plupart des programme que tu cite utilise majoritairement posix, la ou c possible.
le support des peripheriques a grandement evolué sous linux et sous les autres systeme il tend a evoluer aussi de plus en plus vite grace au code de linux.
néanmoins une fois les premier drivers porter vers hurd ou openbeos, leurs possibilité d'evolution est beaucoup plus rapide que sous linux.
Sous hurd ou openbeos le backportage est tres rare car il suffit de rajouter un programme qui gere le peripherique, ou le systeme de fichier par exemple.
tu le l'arrete tu en demare un autre, rien a voir avec la gestion du noyau
et de plus , le systeme et vraiment smp car il n'y a pas d'appel bloquant et temps reel , linux n'est pas temps reel, si tu veux en faire un os multimedia le temps reel doit etre mieux pris en comptes. c important pour offrir une solution utilisable par le plus grand nombre, c quand meme le but des logiciel libre.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Prosper . Évalué à 1.
PS : autre chose c est toi qui disait je sais plus ou que le prochain windows etait basé sur hurd ou un truc du meme genre ?
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Sébastien TeRMiToR . Évalué à 1.
mais microsoft profite de plusieurs avantage:
-support des contructeurs
-des utilisateurs (grande base utilisateur)
-a des milliards a la pelle (marketing, licence anti-concurencielle)
mais hurd a un avantage unique sur microsoft
-liberte, egalité, fraternité , du au code libre
alors que va t'il se passé dans 2-3 ans ?
oui ca m'inquiete , oui c important parce que l'informatique va prendre une part de plus en plus importante dans la vie courante
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par pasBill pasGates . Évalué à 1.
Tu m'interesse la, developpe un peu :+)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par kalahann . Évalué à 1.
ils sont lents, buggués jusqu'à la moëlle, et faits par des gens qui veulent gouverner le monde...
désolé --->[jetienslaporteausuivant]
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par cornofulgur . Évalué à 1.
$ perl -e 'use Text::Soundex;
print soundex("Le Hurd") . "\n";
print soundex("Longhorn") . "\n";'
L630
L526
--->[aiemesdoigts]
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par boubou (site web personnel) . Évalué à 1.
courante
Tu ne serais pas consultant dans une jeune pousse innovante, toi ?
De façon plus directe : t'en n'a pas marre d'enfoncer des portes ouvertes et de recopier 00 informatique (oui, oui, 00) sur DLFP ?
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Sébastien TeRMiToR . Évalué à 1.
tu a dit:
"Linus a jamais prentendu contrbuer au patrimoine de l'humanite mais bon detail"
tous les gens benevole que ce soit par le logiciel libre ou les appuis dans des associations pour aider, transmettre le savoir, le fond bien dans un but precis: ameliore ce qui nous entoure, ce sont des contributions de tout ordres de valeurs, si on ne le fait pas par politique alors pourquoi le faire?
faire de la politique, et avoir des principe c grandir, alors il nous faut grandir tous, aussi toi que moi et linus.
je crois que la liberté est une choses assez sérieuse pour que nos choix dictent notre conduite, si c pas le cas de linus alors il ne peut pas vraiment apporte quelle choses aux autres. (tristement dit :( )
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Gaël Le Mignot . Évalué à 1.
-1 (zut, y'a pas)
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par oliv . Évalué à 1.
ortographe -> orthographe
:-P
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Heu ..
Posté par astennu . Évalué à 1.
[^] # Re: Heu ..
Posté par Arachne . Évalué à 1.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par Eddy . Évalué à 1.
Ce n'est pas parce que tu es a l'etranger que tu peux tout te permettre!
Alors quoi?
La science, elle avance comment?
Hein?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: linux a 11 ans, momment de changer d'air!
Posté par sToR_K . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.