zul a écrit 443 commentaires

En même temps, y'a combien de distributions qui supportent plus de 4 architectures ( ne parlons pas de 10 ca sera malhonnête de ma part).

Comparé Windows, OpenBSD au noyau linux, ce n'est pas très "juste". Le noyau Linux supporte peut-etre plus de plateforme (et encore y'a beaucoup de branches // pour mips et arms pour avoir un support décent) mais quand il s'agit d'une distrib complete, c'est beaucoup moins impressions.

My 2 cts.

Concernant le nombre de licence GPL vs BSD, il faudrait prendre en compte tous ces développeurs qui sont obligés d'utiliser la GPL parce qu'ils utilisent une lib GPL. Forcement avec des choses contaminantes (splashh), on obtient de plus gros résultats.

Les contributions aux projets communautaires sous licence BSD ne disparaitront jamais. Alors arretez d'être de mauvaise foi. Le code ne disparait pas comme ca. Et si il est réutilisé dans un logiciel propriétaire, je préfère de loin qu'il utilise un truc "standard" qu'un truc sale codé par eux et qui ne marchera que pour eux. Si la première pile TCP avait été sous GPL, je préfère pas voir l'état de l'Internet aujourd'hui :).

My 4 cts.

Je dirai que ca concerne beaucoup tes compétences d'admin.

Personnellement je préfère la syntaxe de pf. Mais il faut reconnaitre que netfilter a un nombre très impressionnant de developpeurs et qu'ils ont pu developper des proxy pour les 3/4 des protocoles qui font des choses sales (en commencant par ftp, sip et cie). Tout dépend donc de tes besoins.

Concernant l'amélioration des performances réseaux, il est bien sûr intéressant mais la façon dont il a été fait frise l'hérésie totale du point de vue du logiciel ( et violation de l'abstration mbuf). Mais cela reste un point de vue personnelle :).

J'ai eu l'occassion d'échanger quelques mails avec lui dans le cadre de mon SoC. Il a toujours été d'une aide précieuse.

C'est vraiment une grande perte pour le monde BSD et pour le monde de l'IPv6

Moralement, le but de la communauté libre entière est d'améliorer les drivers et le support en général pour que tout le monde puisse l'utiliser. Ce qu'a fait le developpeur B, c'est qu'il a privé une partie de la communauté du libre ait accès aux améliorations du libre.

Je suis tout à fait d'accord avec Jul et je privilégie l'approche morale à l'approche judiciaire.

La question est de savoir si les 3/4 des devs linux font encore partie de la communauté libre ? A mon avis, non et c'est bien dommageable du point de vue ethique et humain pour le noyau du "système libre par excellence" (mais cela reste mon opinion) (et surtout pour sa communauté).

Les rêves de RMS et cie s'éloignent petit à petit alors qu'on parle toujours plus du desktop linux ...

Un developpeur BSD a ecrit 95% du code. Il le met sous double licence pour que ca plaise à tout le monde. Puis un second developpeur decide de faire quelques modifs et de priver le premier développeur de tout ce qu'il a pu faire (et de toutes les améliorations prochaines).

C'est hautement immorable, bien plus qu'une violation de la GPL, parce que ce sont des "libristes" qui la commettent contre d'autres "libristes" (les uns l'étant beaucoup plus que les autres, je vous laisse le soin de remettre les gens à leur place).

> moyens utilisés pour compiler le binaire

c'est bien vague :). Ils ont encore le droit d'utiliser un compilateur propriétaire pour compiler du code GPL ... Pour la fabrication de busibox, le ./configure et le Makefile sont fournis par busibox.

Quant à generer un binaire identique ... Il te faut leur compilateur, dans la bonne version, dans la bonne langue, ensuite l'ensemble des options qu'ils ont choisis, et ensuite faut esperer que ton compilateur soit deterministe, ce qui n'est pas le cas aujourd'hui des compilateurs performants ( compile deux fois un code non trivial avec gcc, il ne fera pas en general les mêmes optimisations donc le même executable). Multiplie par le nombre d'option de gcc et le nombre d'option de busybox et je te souhaite bien du courage.

Je pense plutot que les .deb et les .rpm sont sous GPL, mais pas que la licence GPL s'etende à l'extérieur des sources (heuresement d'ailleurs).

Je pense que c'est beaucoup de temps et d'argent perdu pour pas grand chose. Même si Moonsoon Multimedia avait fait des modifications à busybox, ca ne leur apporterait pas de plus value (franchement les clients de ce genre de chose doivent s'en foutre comme de l'an 40). Cela ne leur coûterai surement rien de publier leur source (probablement non modifié).

D'un autre côté, attenter un procès pour ca ... Y'a des choses plus graves dans la vie. Surtout un vendredi :).

Que mplayer (ou autre dans le multimédia) ait fait un procès pour ce genre de chose, passe, il y'a potentiellement du code intéressant à récuperer. Pour busibox ...

La prochaine fois, ils utiliseront du code sous BSD :)

> Le pragmatisme de GCC a fait ses preuves. Apple ne serait pas en train de maintenir la partie Objective C de gcc à l'heure actuelle si GCC était sous une licence BSD-like

Cela reste bien evidemment à prouver. On peut se souvenir de khtml et apple. Certes, le code était sous GPL m'enfin on sait ce que ca a longtemps donné ... Il faut aussi voir que le seul utilisateur de Obj C c'est apple et sa communauté. Et même sous une licence BSD-like, je vois pas la plus value qu'ils auraient à garder le code propriétaire.

La question de plus n'est pas là (GPL vs BSD) pour gcc. Le problème vient du design qui a été bousillé pour éviter qu'un module propriétaire ne s'immisse dans la châine de compilation. Ce n'est pas une décision pragmatique, du point de vue ingéniérie....

Quand on commence à me parler de rentabilité financière sur linuxfr, je me dis que le monde va bien mal :) Moi qui était persuadé que le logiciel libre, c'était d'abord une question d'éthique et de partage. Je suis vraiment un gros con ... :D

> Ce n'est pas pénaliser, c'est ne pas voir son code "perverti" en un truc proprio. Si gcc pouvait avoir des greffon proprio, il y a des risques.

Des risques de ? Qu'une société écrive un backend propriétaire ? Et donc ? Cela réduirait la liberté de qui ? Personne ne t'interdirait d'écrire un backend libre, personne même ne t'oblige à utiliser ce backend proprio. Tout comme perso t'oblige à utiliser un module propriétaire sous Linux. La liberté est avant tout un choix ...

> C'est du logiciel libre, ils bossent sur ce qu'ils veulent. S'ils ne veulent pas bosser sur l'architecture bidule, il faut faire avec.

gcc est un logiciel libre certes, mais reveille toi. La majorité des contributeurs de gcc et de linux sont des grosses boîtes qui voient leurs intérets avant tout.

Respecte alors le choix de ceux qui critiquent gcc (en connaissant bien mieux gcc que toi à priori) et qui veulent une alternative plus en adequation avec leurs attentes.

Au passage, merci Miod pour ce petit historique.

Il y'a un truc de sur. C'est une horreur de changer de version de gcc (en particulier de 3 vers 4). L'intégration dans le système de base est difficile, de nouvelles dépendances arrivent, souvent sous GPL, et il faut réfléchir comment les intégrer à l'arbre de source. Toutefois, ce n'est pas impossible. NetBSD l'a fait (en tout cas, pour la 4.1). Mais cela a été long et pénible.

OpenBSD doit possèder gcc 2.95 pour la même raison pour laquelle NetBSD le gardait, à savoir le port VaX.

Le passage en version 4.x leur permettrait
1/ de pas avoir à avoir deux gcc dans leur base systeme
2/ les empecherait de faire du buzz (vu que SSP est de base dans gcc 4.x, OpenBSD n'apporterait plus beaucoup de plus value).

Le passage à gcc4 permet a aussi de corriger divers "bugs" dans NetBSD (d'incorrections en tout cas).

La série 4.x a quand même introduit un warning très chiant, celui qui dit que les variables peuvent être non initialisés, et 90% du temps il se plante. Comme les BSD utilisent -Werror, ca bloque la compilation pour un faux motif et ca oblige à faire une "fausse initialisation" pour calmer gcc.

Sinon, je suis relativement content de gcc4. J'attend l'intégration de gcc 4.2 dans NetBSD.

Ca n'empeche pas qu'il est intéressant de pouvoir compiler les sources avec un autre compilateur. C'est ca aussi la correction et la portabilité du code.

M'enfin, oui la majorité des OpenBSDistes sont des gros trolleurs :) Certains de leurs objectifs sont intéressants mais ils jouent souvent plus sur le buzz et le bruit que sur ce qu'ils font vraiment. (commentaire du vendredi en avance).

Passer d'un compilateur sous GPL portable mais laid à un compilateur en GPL pas portable, pas maintenu et surement pas plus beau (Fabrice Bellard est un génie mais la qualité du code est parfois plus que douteuse, et le code est quand meme basé sur un code IOCC ...), ca serait en effet une grande avancée :).

tcc n'est tellement pas maintenu qu'il existe un "bug de securité" connu depuis Février 2006 et toujours pas corrigé dans une release ...(http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-0635).

Sinon la GPL c'est du tout bon .... pour les avocats :). Pour le reste, cela reste à prouver ...

Yaka :)

Je te conseille d'ouvrir les sources de gcc. Tu comprendras tout de suite pourquoi il est difficile de corriger un bug, quand tu n'es pas un gourou gcc.

Tu as l'air très doué. Je pense que tu va pouvoir aider la communauté BSD... Yapluka

J'admets, j'admets, je n'ai pu m'empecher de résister au troll.

Toutefois, je suis convaincu de l'ininteret de rentrer pcc dans le cvs de OpenBSD.

Tout d'abord, parce que ca ne sert à rien pour 99,99 % des utilisateurs d'OpenBSD.

Deuxièment, parce que ce ne va pas accélérer le developpement de pcc en tant que projet externe. Ils vont devoir synchroniser regulièrement leur arbre de source avec celui de pcc (actuellement ils le font à la main ...) et ensuite ils vont faire une modification dans leur arbre puis au mieux remonter dans pcc la modification (et ils verront un bon conflit apparaitre lorsqu'ils synchroniseront les arbres de source).

Je ne vois donc pas l'interet d'avoir intégrer pcc à l'arbre de source, sauf evidemment si ils comptent "forker". M'enfin nous verrons bien.

pcc n'a pas été importé dans NetBSD mais dans pkgsrc aka il est plus facile d'installer et de suivre les modifications de ce logiciel (et pkgsrc supporte bien plus que NetBSD comme Os cible).

Pcc permet de compiler les sources de NetBSD/i386. Cela permet surtout de vérifier que le code est portable , et de détecter un certain nombre de gnuisme. Pour l'instant l'impact de pcc s'arrête la pour NetBSD.

Apres espie@OpenBSD.org a très bien expliqué les nombreuses raisons pour lesquelles ils seraient souhaitable d'avoir un autre compilateur de gcc. Rappellons par exemple qu'on a jamais reussi a booter un kernel VaX avec gcc3 ...

C'est à mon avis bien trop tôt pour intégrer pcc au cvs d'OpenBSD mais rien ne m'etonnent de leur part (ils feraient mieux de contribuer directement à pcc m'enfin je suis sur qu'ils vont préférer écrire OpenCC dans leur coin).

Sous Jabber, le message est envoyé N fois à chaque serveur, ou N est le nombre de client de ce serveur sur le MUC.

Bon, ça c'est complètement faux. Tu sais combien il y a de serveurs Jabber sur internet ? Ensuite, les messages et infos de présence d'un MUC ne sont envoyés qu'aux clients connectés à ce MUC, en passant via leur serveur respectif, le cas échéant. C'est donc le minimum, on ne peut pas faire moins, donc optimal. Ça ressemble de très près à ta description du fonctionnement d'IRC.


Si N == 0, on n'envoie pas le message. Si N est 1, c'est optimal. Pour N > 2, on envoie plusieurs fois le message au serveur, pour qu'il le relaye à chaque utilisateur. Sur IRC, le message est envoyé 1 fois au serveur pour qu'il soit relayé au N utilisateurs de ce serveur. Ce n'est donc pas efficace.

voir http://mail.jabber.org/pipermail/standards/2006-February/010(...) pour un dessin.

Avoir une norme lisible c'est bien. Avoir une norme implémentable et implémenté c'est mieux.

La simplicité côté CLIENT? Merde alors, va falloir revoir Jingle parce que tout le boulot se fait sur le client. Quand au status actuel des clients, oui c'est lamentable. La moitié des clients gèrent meme pas le discovery de service, et les MUCS ont un support plus que variable. Je ne parle pas de features moins courantes (genre le whiteboard de cocinnella) (j'ai testé gaim, gajim, psi, cocinella, mcabber, kopete ...).

Je n'ai pas la haine contre XMPP. J'ai une adresse XMPP comme tu peux le voir, je l'utilise tous les jours comme IM. Mais je n'attend pas la même chose d'IRC et d'un IM. Je n'ai aucune haine contre XMPP. Je pense juste qu'a force de vouloir devenir trop "universel", il ne parviendra qu'a être médiocre. Si il veut vraiment avoir un créneau sur le domaine des MUC, il faut revoir je pense 1/ les technos de routage utilisées 2/ revoir les clients. Et encore, je ne suis pas sur que cela suffise à faire switcher les gens d'IRC à XMPP (les habitudes sont difficiles à changer). Il faudrait que les Mirc et Xchat ajoutent un support MUC pour que les utilisateurs migrent en douceur.

Je pense que ton interpretation des chiffres est incorrect. Un bon nombre de chan ont une base de 0 utilisateurs (1 peut-etre avec le bot du réseau). Et les utilisateurs sont souvent sur plusieurs chans à la fois.

<my life> Les chans que je frequente sur Freenode sont souvent plus pres de 100 utilisateurs que de 10 utilisateurs </my life>

Concernant l'efficacité, IRC requiert que chaque message soit broadcasté UNE fois à l'ensemble des serveurs (à l'ensemble des serveurs "contenant" au moins une personne du salon). Sous Jabber, le message est envoyé N fois à chaque serveur, ou N est le nombre de client de ce serveur sur le MUC. Bravo l'efficacité.

On critique les 5 RFC de IRC. Regardons XMPP :). 6 RFCS (3920, 3921, 3922, 3923, 4622, 4854) et pas loin de 200 Xeps. Et XMPP est un protocole jeune. Les implémentations des serveurs divergent plus ou moins, la norme étant d'une complexité assez impressionante. Et je ne parle pas des clients....

Non le portrait de XMPP n'est pas forcement beau à voir. Oui c'est le protocole libre de demain, qui va resoudre tous nos problèmes informatiques. Peut-etre qu'a force de vouloir être le meilleur dans tout, il ne sera meme pas bon dans un seul domaine ....

Je ne suis pas un expert jabber. J'ai commencé à lire les rfc core de xmpp à un moment mais je me suis arrété la, je n'ai pas lu l'ensemble des XEP proposées depuis.

Les auteurs de ces pages me semblent relativement compétents, à savoir qu'ils ont réfléchis aux problèmes de IRC et co et qu'ils ont proposés une solution. Ils ont aussi implémentés assez d'IRC et de XMPP pour que l'accès à Psyc soit "transparent". Il est probable aussi que leur(s) avis soient biaisés et qu'ils défendent leur solution.

Le seul reproche que je fais à XMPP au final, c'est d'essayer de créer un protocole permettant de résoudre n'importe quel problème :). Encore un produit miracle qui lave plus blanc que blanc. Enfin ca veut dire quoi derrière ? Ca veut dire que les serveurs sont compliqués à implémenter, que les clients sont aussi extrèment compliqués à implémenter, et qu'en plus, il faut avoir un design assez souple pour pouvoir assurer qu'on va pouvoir intégrer les 200 prochaines XEP qu'on va nous pondre. A des années lumières du mouvement KISS.

IRC a l'avantage d'être un protocole simple, et on a vu deja les "dizaines" de bug d'implémentation des différents serveurs. Je ne vois pas comment cela pourrait être mieux avec XMPP, qui devient chaque jour plus difficile à implémenter.

Enfin, 25 users sur un chan c'est ridicule (pour IRC).

NB : J'utilise XMPP en tant qu'IM je ne suis pas un anti-jabber. J'aimerai juste que cela reste un protocole simple et non un truc qui essaye de résoudre tous les problèmes du monde.

Jabber a aussi de nombreuses faiblesses au niveau des MUC. En particulier un sérieux problème de charge réseau. La page http://about.psyc.eu/Jabber référence différents problèmes associés à XMPP. Il décrit aussi les problèmes associés à IRC (faut pas faire de jaloux).

Apres tout dépend du contexte. Les réseaux internes sont surement très bien avec du XMPP. Pas de problème de scalabilité réseau, et plein de services associés. Apres, pour monter un réseau de la taille de freenode over XMPP, j'ai des doutes.

Psyc a l'air d'être une alternative intéressante. Evidemment, il n'y a pas de vrai client, la seule implémentation est écrite dans un langage peu connu, je doute que ca perce fort. Mais ils ont des approches intéressantes pour les problèmes de Routage des messages.