vosgien_ a écrit 47 commentaires

Quand Theo parle du noyau linux alors Theo est lié à linux ? C'est n'importe quoi.

Le développement récent de PCC n'a rien à voir avec OpenBSD, mais est la volonté de ragge (à l'origine de NetBSD) qui en avait besoin.

Au sein d'OpenBSD, un développeur (otto) s'est intéressé aux qualités du compilo, et après des discussions avec d'autres devs et Theo, il a été importé. Ca a également été le cas pour NetBSD.

Ce que je trouve vraiment stupide, s'est d'affirmer des choses au sujet d'OpenBSD qui sont fausses. Un coup marketing d'OpenBSD ?? Tu crois que ragge a été payé par Theo pour relancer PCC et puis donne des pots de vins aux autres BSD pour travailler dessus ?? Arrêtons les blagues... PCC n'a pas attendu OpenBSD...

J'étais certain qu'un tel article (très bien écrit et objectif de surcroit) sur linuxfr déclencherait des commentaires de fanatiques comme celui-ci ou les habituelles baves de patrick_g (qui n'a d'ailleurs pas manqué à l'appel ;) ).

Pour répondre calmement...

Hum, PCC est un compilateur C, soit. Mais de là à oser dire qu'il est un concurrent à GCC, faut pas abuser.

Dans l'article il est parlé d'alternative à GCC au sein du système et pour compiler celui-ci. A quoi cela sert de savoir compiler du fortran, du java, etc. dans la base d'un os ? Pas grand chose.

GCC sait compiler bon nombre de langages, PCC se concentre sur le C, et c'est en cela qu'il peut représenter une alternative à GCC (ragge parle d'ailleurs d'ajouter plus tard le support d'autres langages comme le C++).

OpenBSD ne veut que du code BSD quitte à réinventer à la roue (carrée) et user de FUD sur ses concurrents.

PCC n'a rien à voir avec OpenBSD ou Theo. C'est un projet commun à tous les BSD et l'association en charge de la collecte des fonds s'occupe de tous les BSD sans préférence... D'ailleurs, ragge, le mainteneur de PCC est l'ancien mainteneur de l'archi VAX de NetBSD...

Bref, rien à voir comparé à la blague qu'est PCC.

Pourquoi être si insultant ? PCC est un compilateur C petit, portable, très rapide et produisant des binaires relativement bonnes.
Du fait de ces avantages et de sa licence il a tout pour intéresser les systèmes BSD qui souhaitent avoir un bon compilateur C (et rien d'autre) pour l'os de base... Alors oui, la route est encore longue et PCC n'avait pas été maintenu depuis des lustres... mais tous les projets libres commencent bien un jour non ? Pourquoi tant de haine ?

J'ajouterais que FreeBSD et NetBSD ne sont pas basés sur 4.4BSD qui est sorti *après* (juin 94), mais sur 386BSD, lui même basé sur 4.3BSD (Net/2).

Rappelons au passage que OpenBSD est issu d'un fork NetBSD, lui même issu d'un fork FreeBSD, ce dernier étant partie d'une 4.4BSD.

OpenBSD est bien issu d'un fork de NetBSD. Par contre NetBSD a démarré en parallèle de FreeBSD et n'a jamais été un fork de ce dernier. Savoir le quel des deux a débuté avant l'autre est un peu flou... Au début ils ne représentaient qu'un ensemble de patchs de 386BSD.

Au niveau release officielle, la première de NetBSD (0.8) date d'avril 93, la première de FreeBSD date de décembre 93 (1.0).

Il a toujours évité le problème et a toujours dis que c'était "une simple erreur".
Non, il n'a jamais évité le problème. Il a reconnu qu'un dev avait fait une erreur, et le code a été retiré immédiatement. Je ne vois pas ce que tu veux de plus...

théo est partis sur ses grand chevaux.
Les développeurs d'openbsd ont une vision du logiciel libre qu'ils ne partagent avec peu de gens, c'est vrai. Le fait d'hurler sur tous les toits "vous nous avez volés volontairement du code blahblahblah" ce n'est pas règlo. Joindre les développeurs en privé aurait été aussi efficace.

Et là, effectivement, openBSD c'est servi en changeant la licence.
Voire http://thread.gmane.org/gmane.linux.kernel.wireless.general/(...) et la réponse de Théo qui nie le probléme !

Mais combien de fois faudra-t-il le répéter avant que les gens arrêtent de propager ces mensonges...
Theo n'a jamais nié le problème. D'ailleurs, dès que Theo et le développeur en question a eu vent du problème, ils ont immédiatement supprimés le code.

La licence GPL est dite virale, parce que le code qui découle ou s'appuie d'un projet sous licence GPL doit être lui aussi sous GPL.

Une licence de type ISC/BSD n'impose pas cette contrainte : le code dérivant d'un projet sous licence ISC/BSD peut être placé sous n'importe quelle licence qu'à choisi l'auteur, y compris propriétaire.

Par contre, ce qui est interdit par la loi, c'est de changer une licence sans l'accord de l'auteur. Quelque soit la licence, il est interdit de prendre du code sous une certaine licence et de le "relicencer" sous une autre licence lors de son inclusion à un projet.

En gros, la licence GPL permet de piocher dans nombre de projets libres sans avoir à redonner en échange si l'autre à une vision du libre qui n'est pas GPL (c'est uniquement suivant le bon vouloir de l'auter, s'il publie sa modification en licence multiple ou non...).

Attention : si l'auteur du code ISC n'a publié son code que sous licence ISC, ce code peut être inclu dans du code sous GPL, à condition que le code sous licence ISC *reste* sous licence ISC.

C'est à dire que quelqu'un qui inclut du code ISC dans un fichier source sous GPL doit ajouter la licence ISC pour le code ajouté. Ne pas le faire est *illégale* : cela correspondrait à changer la licence originale du code sans accord de l'auteur, ce qui est interdit par la loi.

La licence ISC est très claire :
Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

Les groupes d'interfaces n'ont rien à voire avec PF... Ca concerne les interfaces. Et comme tout ce qui concerne les interfaces se fait sous OpenBSD avec ifconfig... tout est logique.

D'après la citation que tu fais de CLUSTERIP, je dirais que les avantages avec PF sont :
-- possibilité de distribuer le trafic au delà de routeurs (CLUSTERIP semble n'accepter que des adresses MAC),
-- possibilité de distribuer les connexions avec plus de flexibilité : algorithmes plus nombreux,
-- possibilité de faire du load balancing de niveau 3 ou 7 en combinant avec hoststated.

Après je ne connais pas le fonctionnement de CLUSTERIP en détail.

egress fait partie de la mise en place des groupes d'interfaces : c'est le groupe, crée automatiquement, qui contient l'interface où se trouvent la/les route(s) par défaut.
Ces groupes d'interfaces se configurent avec ifconfig.

Tu peux écrire ton fichier pf.conf avec des noms d'interfaces ou de groupes. Tout fonctionne de la même manière.

L'avantage avec egress est la portabilité puisque tu n'as plus besoin de te soucier de la portabilité de ton fichier si tu change de machine ou de carte réseau pour ta passerelle.

C'est aussi utile dans d'autres cas : par exemple, pour mon laptop, j'ai un seul fichier pf.conf écrit en fonction d'egress. Dès que je bascule sur le wifi, le basculement se fait automatiquement par PF, je n'ai pas besoin de recharger les règles.

Avec les groupes tu peux aussi faire des choses très intéressantes et simplifier grandement ton fichier. Imaginons que tu gères un routeur/firewall avec de multiples interfaces ayant les mêmes politiques, elles peuvent toutes être rassemblées dans un seul groupe. Une seule politique de filtrage pour le groupe est nécessaire.

Avec le protocole roundrobin de trunk(4), tu répartis la charge sur tous les liens. Le problème vient de certains switchs qui posent problème avec ce mode.

Si tu as de nombreuses connexions avec des en-têtes ethernet différentes la charge peut également bien être répartie avec le protocole loadbalance, et il marche avec nimporte quel switch.

Mais attention, l'aggregation de lien ne permet jamais d'obtenir vraiment débit totale = (débit interface * nb interface). Il est possible de s'en approcher dans certaines conditions mais s'est pas toujours évident pour certaines configs.

A noter que le trunking c'est aussi très utile si tu perds des liens en route puisque tu peux continuer de tourner sur d'autres.

Je connais pas LACP avec agr(4), mais d'après ce que j'ai pu lire sur la page de man sur le site de netbsd, il a les mêmes problèmes que trunk(4) : http://netbsd.gw.com/cgi-bin/man-cgi?agr++NetBSD-current

Le trunking d'OpenBSD, donc celui repris par FreeBSD dispose de plusieurs protocoles comme indiqué dans la page de man :

-- roundrobin : permet de distribuer le traffic sur plusieurs interfaces membres du trunk. Si une interface membre a un soucis ou est déconnectée, le trunk continue de fonctionner normalement sur les interfaces restantes.

-- loadbalance : distribue le traffic sur les différents ports en fonction d'un hash de l'en-tête ethernet. C'est ce que font la majorité des constructeurs de switchs lorsqu'ils implémentent du trunking/etherchannel, etc. Il se peut que le mode roundrobin ne fonctionne pas avec certains switchs, ce mode permet donc d'utiliser le trunking avec tous.

-- failover : on déclare une interface en maître et les autres en esclave. Tant que l'interface maître est active on tourne dessus. Lorsque l'interface maître passe inactive, la première interface esclave prend le relais. Si l'interface déclarée maître redevient ok, on rebascule dessus.

C'est ce dernier mode qui est très utile pour les portables : on peut tourner sur le gigabit tant qu'il y a de la connectivité. Si on débranche le câble, le basculement se fait tout seul sur le wifi. Attention : le traffic ne passe que par *une seule* interface à la fois avec ce protocole.

Néanmoins je persiste et je signe : Ces modèles ne peuvent pas être qualifié de "récents"

Mais on parle de la famille pentium M depuis le début, pas de tous les processeurs i386 possibles et imaginables...
Les modèles supportés par le driver speedstep de netbsd 3.1 sont les modèles *récents* de pentium M, il n'y a pas à être d'accord ou pas, c'est les fait.
Les processeurs Core c'est une autre famille, qui ont bien d'autres caractéristiques.

C'est certain que c'est loin d'être parfait et que j'aurais du préciser plus les choses sur les modèles de Pentium M.

Ce que je repproche à ta remarque sur le support du speedstep c'est de faire passer netbsd pour un système préhistorique, loin derrière linux, alors que ce n'est pas le cas.

La performance c'est Linux et peut-être FreeBSD.

Tu as des benchs précis ? On parle de quelle utilisation ? Desktop ? Serveur (de quoi ?) ? Routeur ?
Les performances de NetBSD sont loin d'être ridicules...

Le support du matos c'est Linux.

Non. Le support du matos PC, éventuellement amd64 et macppc.
Pour toutes les autres architectures le support sur Open/NetBSD est majoritairement bien meilleur.

C'est une blague ? Des modèles récents ?

On parle de *pentium M*. Oui, les modèles 710, 730, etc, sont les versions récentes de pentium M, que tu le veuilles ou non...

Ton article est simplement pas le reflet de la réalité, puisque ce que tu avances concernant le pentium M est faux : le speedstep est supporté depuis longtemps. C'est juste un ajout pour les derniers modèles qui s'est produit dans NetBSD 3.1, comme ça a été le cas pour OpenBSD 4.0.

Après, tu parles du i915 et de XFree, ce n'est absolument pas l'objet de ma première remarque. Tu divagues.

Ton article d'origine dit :

gestion du SpeedStep sur les Pentium M

Ce qui est complètement faux, puisque le speedstep est supporté par NetBSD sur les pentium M depuis longtemps (au moins la 3.0, parlons de versions stables). Tu sembles oublier qu'il y a eu plusieurs générations de Pentium M...

Pour les modèles récent (710, 730, etc.), il faut replacer un peu le débat. Mon portable est sous OpenBSD, et il a fallu que j'attende OpenBSD 4.0 (sorti il y a quelque jours) pour pouvoir bénéficier du speedstep ; c'est un pentium M 750.

Et pourquoi ? Parce que intel ne fournit plus les valaurs auxquels peut tourner ses proc (alors qu'il le faisait pour les premières versions de Pentium M). On ne peut maintenant s'appuyer que sur l'acpi.

LFS ?

Il faut pas confondre les architectures supportées par le noyau linux, et les architectures supportées par un système COMPLET.

Oui, le noyau linux est disponible pour beaucoup de plateformes. Par exemple IBM a mis à disposition les sources pour le faire tourner sur cell. Mais IBM fourni un système linux complet, libre, qui tourne sur cell et installable par tout le monde ?
Le cell c'est qu'un exemple...
Et puis avoir le toolchain et le compilateur qui fonctionne sur toutes les plateformes supportées par le noyau c'est une bien autre histoire.

NetBSD est un système complet qui fonctionne de la même façon sur toutes les architectures supportées. Pas de bidouille d'un côté ou de l'autre.

Si on veut parler objectivement, il faut parler du système complet, pas d'une petite partie seulement. Et là, niveau portabilité, NetBSD est loin devant...

gestion du SpeedStep sur les Pentium M c'est que ça me paraissait incroyable qu'il ai fallu tout ce temps pour obtenir ce support.

Tien, en regardant la release note de NetBSD 3.0 qui est quand même sortie il y a près d'un an je vois :
The i386 port now supports the Enhanced SpeedStep Technology.
Et en regardant le CVS de plus près, je vois que le driver "est" a été ajouté le 30 avril 2004.

J'écris ce message depuis un Thinkpad T43 sous OpenBSD 4.0-beta (-current).
Le support est tout simplement parfait. La seule chose qui ne fonctionne pas est le lecteur d'empreintes digitales... mais bon.
Sous les systèmes BSD et plus particulièrement sous OpenBSD c'est un pur bonheur ces Thinkpad's.

Cet argument est complètement stupide. Ca me rappel les arguments traditionnels Windows/Linux : "ouihh euhh sous linux mon matériel derrnière génération n'est pas supporté, il faut attendre des mois, alors pourquoi je quitterais windows, tralalalalalalalala".

Si tu choisis CORRECTEMENT ton matériel, il n'y a pas de problème, avec quelque système que ce soit (linux, *bsd, *solaris, windows...).

J'ai eu un portable acer il y a quelques années, que ce soit Debian ou Ubuntu, elles ont toutes refusées une install normale pendant plus de 6 mois.

Est-ce que pour autant c'est la faute de la distrib ? Est-ce que c'est la faute de Linux, des développeurs ? Je ne crois pas. Si les développeurs n'ont pas le matériel pour tester, il ne peuvent que très difficilement ajouter du support pour ce matériel. Et acheter la totalité des configurations possibles de la planete, je ne connais pas d'entreprise et encore moins de particuliers qui peuvent le faire.

Ajoutons à cela que bien souvent le matériel non supporté vient du fait que les fabricants ne donnent pas les docs pour supporter leur matériel.

Ton argument est donc bancale, et tu ne peux t'en prendre qu'à toi. Si tu voulais vraiment faire tourner ton système préféré, tu aurais choisi la machine/constructeur approprié.

Ce n'est pas du tout le débat. Je n'ai jamais dit que l'initiative était à rejetter... justement l'attitude de Sun depuis quelques temps est excellente.
Je ne comprend pas pourquoi tu dis que je critique...

Et non faire la doc d'un process c'est pas forcement "trivial" comme il le dis.
Quel que soit sa contribution.

Il a été le responsable du port sparc à l'époque ou il était encore dans NetBSD, et ses sontributions au port OpenBSD sont très importantes (comme le fait de booter un seul même kernel pour toutes les machines sun4, sun4c, et sun4m alors que Solaris n'en est pas capable).
Alors il me semble - sans vouloir te froisser - qu'il connaît un peu mieux le sujet que toi.

Il ne faut pas oublier que la libération ne s'adresse pas qu'a monieur theo , mais a toute la communaute, donc ca interesse AUSSI la communaute qui développe du hard libre, etc...

Oui, c'est justement pourquoi Théo réclame un tas de documentations aux différents constructeurs. Ce n'est pas QUE pour OpenBSD, c'est tout le monde qui bénéficie des différentes actions qu'il mène.

Et non adapter du code pour qu'elle utilise au maximum un processeur ce n'est pas trivial si tu n'as pas la doc qu'il faut.

C'est ce que je dis depuis le début... Il faut de la *bonne*.

C'est dommage que chaque discussion sur OpenBSD et Théo devienne tout de suite agréssive.

Je ne vois pas le rapport, le projet F-CPU vise à créer un processeur risc aux spec libres, pas d'écrire du software qui tournera sur une architecture.

Il y a une grosse différence entre concevoir de A à Z une architecture, et écrire du software qui tournera dessus.

Par exemple pour écrire un driver, il n'y a pas besoin de connaître les schémas électriques de la carte : de la *bonne* doc suffit.

Enfin je pense que Théo a suffisement contribué aux architectures sparc (que ce soit sous NetBSD à l'époque où il en faisait partie ; ou OpenBSD) pour dire qu'un processeur est trivial à comprendre comparé aux chipsets.

Ce qui me gêne moi, dans l'attitude de SUN par rapport au libre, c'est qu'ils semblent ne libérer que des produits en fin de vie.

L'architecture liberée par sun concerne les nouveaux processeurs UltraSparc T1 : nom de code Niagara (sun4v) dont les premiers exemplaires seront disponibles début 2006 dant les modèles SunFire T1000 et T2000. Ce ne sont PAS les produits en fin de vie.

Pour info ces modèles sont des 4/6/8 cores dont chacun des cores, comme tout processeur risc peut faire tourner 4 threads.
Ce qui fait jusque 32 threads dans un seul processeur !