Il permet apparament la meme chose que CARP + pfsync, je pense essayer de le mettre en place dans quelques jours.
Tu es sûr de ça ? Si c'est le cas c'est très bonne chose !
La dernière fois que j'ai testé lvs il ne permetait pas de faire des firewall redondants faute de partage des tables d'états de netfilter (je ne parle pas des états dans la gestion des connexions interne à lvs).
CARP est plutôt une implémentation libre des protocoles vrrp/hsrp que l'on retrouve sur les routeurs de réseaux.
Non, c'est un autre protocole. Inspiré des idées de hsrp, mais conçu différement et non compatible ; en particulier, quelques améliorations concernent la sécurité, notament via checksums des datagrames. Par ailleur HSRP est breveté par Cisco ce qui est plutôt génant pour certains.
CARP est avant tout basé sur le failover d'IP alors que Heartbeat est basé sur du failover applicatif, y compris IP. CARP est donc plus légé qu'Heartbeat mais plus spartiate de premier abord, le tout était de toute façon scriptable.
Il semble qu'un paradigme de CARP sous OpenBSD (en fait d'open en général amha ;) est de faire en sorte que les choses restent très carrées et propres: avec une conf simple, minimale, et pas de shell script. Pour preuve: le complément scriptable dédié au failover applicatif d'OpenBSD, ifstated, existe. Et bien que parfaitement stable, il n'est pas connecté au build, maintenu quasiment "secret" (il est dans les sources mais ne compile que si on le connais et si on ne réclame explicitement sa compilation).
Précisons que CARP (Common Address Redundancy Protocol) est surtout un protocole visant l'automatisation des procédures de detections de pannes et failover (reprise en cas d'indisponibilité) au niveau IP.
L'objectif principal est la haute disponibilité (la répartition de charge en bonus). Couplé avec d'autres outils importés d'OpenBSD (pf, pfsync) il permet notament la haute disponibilité des firewalls par redondance, repartition des tables d'états et reprise automatisée d'adresses IP.
La participation d'Apple à divers logiciels open source (khtml, mais aussi les utilitaires BSD, gcc etc) n'est pas négligeable.
En revanche ils se montrent très peu coopératif lorsqu'il s'agit de diffuser les spécifications de leurs chipsets (des chipsets qu'ils utilisent) et lorsque celà concerne les droits de diffusion des firmwares nécessaires à ces chipsets.
Apple choisit souvent des fournisseurs parmis les moins coopératifs (Broadcom et Ati par exemple) et refuse très souvent (malgrè une forte demande des devs noyau Linux et *BSD) de livrer les spécifications détaillées (ou de demander à ses fournisseurs de le faire, après tout Apple est là en position de force) et des licences adéquates pour la distribution des firmwares et drivers binaires.
Concernant la remontée des contributions en upstream, elle n'est parfaite pour aucun Unix (Mac OS X compris) et aucune distribution GNU/Linux. Les developpeurs "upstream" ont depuis longtemps apris à aller chercher d'eux même dans les bugtrackers et les patchsets des divers distros (et dans les ports *BSD). Ou pas.
Je voulais dire que le système de base n'est pas dépouillé au point d'être inutilisable en l'état, qu'il inclus beaucoup de logiciels, comme le montre le volume de leurs sources (sources qu'on peut installer ou pas mais ce n'est pas la question).
> * Un ensemble minimaliste de programme pour que l'OS tourne
Enfin, minimaliste, c'est très relatif :
FreeBSD 4.9: 373M /usr/src/
OpenBSD 3.6: 590M /usr/src
Dont environ 100Mo de kernel (/usr/src/sys/) dans les deux cas. Et X.org non compris.
Pour le prix on a perl, sendmail, pop3d, un serveur kerberos, parfois apache (pour open) bien audités... bref souvent de quoi faire un serveur sans utiliser les ports/pkgsrc/packages.
Sans être un militant de la licence BSD au mépris de la GPL (j'aprécie les deux licences), je vais quand même intervenir en sa faveur parcequ'elle a aussi de bons cotés, et que les lecteurs de linuxfr (que je suppose majoritairement linuxiens) pourraient ne pas les connaitres, et tirer des conclusions hatives en lisant des messages comme le tien (qui sont fréquents ici).
Certains apprécient la licence BSD (3 clauses, et aussi la MIT) justement parcequ'elle offre une grande très compatibilité avec les autres logiciels (elle est compatible avec la GPL -et la réciproque n'est pas vraie-, la LGPL, la MPL, avec n'importe quelle licence close source et proprio etc.).
Pour ceux-là, le fait de voir son code repris par un autre logiciel (eventuellement GPL ou propriétaire) n'est pas forcément génant (c'est plutôt une bonne chose, à minima un gage de reconnaissance).
Celà permet par exemple une large adoption d'un concept ou d'un protocole au départ developpé par un petit groupe peu influent.
Par exemples, le choix de X11 par les divers unix (propriétaires ou pas) est une très bonne chose permise par la licence à l'époque très ouverte de XFee ; idem pour la couche TCP/IP: l'implem d'origine, sous licence BSD, a permis à celle-ci de d'être adoptée aussi par les OS proprios, à une époque où les couches réseau maison en concurence étaient légions (et je suis heureux de ne pas vivre dans un monde netbeui ;) ; voir aussi, aujourd'hui, le travail de kame autour d'IPv6, ou de l'ISC avec bind, dhcpd et inn.
Quand une implémentation libre, (très) ouverte et documentée devient un standard de fait, en lieu et place de solutions propriétaires, c'est toute la communauté du libre qui en bénéficie (y compris le projet GNU). Dans ce cadre la licence BSD a toute sa place.
On peut aussi se réjouir du choix de licences permissives pour PHP, python, perl et ruby qui permet l'utilisation de ces logiciels en entreprise (eg. pour faire d'autres softs, close source). (histoire de rechauffer le tro^H^H la dépeche sur le choix de la licence de java par sun ;).
Dans le même ordre d'idées, le projet OpenBSD (dont les developpeurs maintiennent aussi OpenSSH) milite pour un internet sécurisé. Le fait que Cisco utilise maintenant le code d'OpenSSH (sous licence BSD) rend les réseaux plus sûr, et par conséquent diminue le risque d'attaques pour tout le monde (y compris les utilisateurs d'Open). Donc le choix de la licence contribue à l'objectif de sécurité (comme s'ils disaient "volez notre code, il est robuste et audité, et nous ne voulons pas que nos voisins aient la peste").
Concernant le risque de voir un projet BSD disparaitre à cause de la fermeture du code, il est plutôt théorique sur les gros projets (ormi apache et son abominable nouvelle licence). MacOSX et BSDOS n'ont pas tué FreeBSD, les developpeurs ont déserté le projet XFree lorsqu'il a changé de licence (et X.org semble bien se porter), etc. Bref, il est probable que les logiciels propriétaires utilisant du code BSD améliorent les projets BSD plus souvent qu'ils ne leur font du tort.
Pour finir, l'auteur (detenteur du copyright) d'un projet GPL peut lui aussi décider de refermer son travail. Au moins pour "ses" fichiers. Mais c'est là aussi très théorique.
> (j'espère qu'en te citant je ne déforme pas tes propos; si tu ne veux pas qu'on utilise des extraits de tes messages indiques le; c'est ton droit
Je me suis mal exprimé. Le problème n'est pas vraiment dans le fait de citer, mais dans ta réponse, qui s'applique à une idée partielle eventuellement un passage d'un message qui dans l'ensemble peut dire autre chose (voir l'inverse); Celà permet de faire dire (et de répondre) tout et n'importe quoi. Mieux vaut répondre aux idées globales exprimées dans le message (et l'usage de la citation peut appuyer une explication dans ce cas) que, mot pour mot, à des segments de phrases (des propositions isolées).
Pas besoin de faire des disclaimers hystériques, il suffit d'un peu de bon sens (ou de bonne foi ?).
> C'est tout autant valable dans l'autre sens.
Bien sûr ; je pense même que c'est valable pour à peu près tout les unix (un logiciel posix qui n'est pas portable sous windows ou os/2 etc. n'est pas forcément sale, les environement sont trop différents).
Aussi, quand il y a un portage, la taille du patch nécéssaire est un bon indicateur à mon avis.
> Comme beaucoup de code qu'on retrouve dans BSD est en premier développé sous Linux, j'en conclus que les développements sous Linux sont majoritairement de qualités.
Non, je pense surtout que les developpeurs travaillant sous GNU/Linux sont plus nombreux. Ça ne signifie rien concernant la proportion de bon code / mauvais code.
> Comme il y a peu de transfert BSD vers Linux, j'en conclus que BSD ne fait pas grand chose.
Il y a tout de même beaucoup de transferts BSD vers Linux (et n'oublions pas que des morceaux de code BSD/MIT peuvent être inclus dans des logiciels GPL, inclusion impossible dans l'autre sens, ce qui est un avantage pour ceux qui aiment la licence BSD/MIT/ISC: elle est très "portable" ;), compatible avec beaucoup de choses, mais je dérive là ...).
Sinon je t'accorde que les contribution dans ce sens sont peut être un peu moins nombreuses que les utilisations de logiciels developpés sous Linux sous BSD (surtout si l'on parle d'environement destkop) ; mais là encore, cette remarque n'exclu pas la possibilité qu'il y ai moins de developpeurs sous BSD, mais des developpeurs très actifs et écrivant du code de qualité.
J'applique cette "mini évaluation" rapide au cas par cas (logiciel par logiciel) (et souvent assortie d'une session dans les bugtrackers pertinents).
>> - c'est intégré/fonctionel - et pour cause, joli coup de pub (hein fabb ?)- uniquement dans fedora (et encore en béta non ?).
> Tout est un upstream tocard.
Tu a bien vu, en lisant la suite de mon message, que je le sait.
Tu semble d'assez mauvaise foi sur le coup, parceque tu répond à des faits évidents en citant des bouts de phrase, et ce faisant tu masque la question de fond soulevée (ps: j'ai remarqué que tu fait ça dans presque tout tes posts polémiques).
> De tout manière votre rhétorique est connu : si c'est Red Hat qui fait le boulot alors c'est nul
> [...]
> Qui fait des efforts pour OOo à part Sun ? Pratiquement personne.
Absolument pas, c'est très bien que redhat améliore les choses.
Simplement on peut trouver, puisque c'est la question soulevée par cette dépèche, que l'absence d'efforts sur la portabilité et le choix de java _de la part d'ooo_ (pas de ton Dieu) ne rend pas forcément le projet affriolant pour le dev.
>> ça fait un peut passage en force de la part de sun
> Sun fait pratiquement tout le boulot donc ils font ce qu'ils veulent.
Oui, et gageons que dans ces conditions, ça ne changera pas facilement.
> y a-t-il OOo 2 pour les *BSD ? Non.
Typiquement, c'est une façon simple d'avoir un indice la qualité du code d'un soft. S'il est assez connu et n'est pourtant pas dans /usr/ports/ ou /usr/pkgsrc/, c'est souvent qu'il y a quelque chose de pourri dans le royaume (qualité du code, gnouteries, licence, ...).
> Oh non par pitié, s'ils restent entre eux, ils vont nous pondre une version graphique de vi... :-P
> J'entends par là que les programmeurs n'utilisent pas toujours (jamais ?)
C'est sans doute une des raisons du probleme. C'est pas forcément très sexy à priori, le developpement benevole d'une suite bureautique (surtout dans le cas d'un bloatware shooté au java).
Beaucoup moins que de jouer avec le noyau linux je pense (il semblerai que dans ce cas, à contratrio, le problème soit quasiment le surnombre des contributions !).
>> HAHAHA ! je veux pas relancer le troll mais c'est a cause de java que tout le monde c'est barré ou y'avait deja personne avant ???
>Cette remarque est aujourd'hui avec gcj4 "nulle".
Sûrement pas:
- c'est intégré/fonctionel - et pour cause, joli coup de pub (hein fabb ?)- uniquement dans fedora (et encore en béta non ?).
- pour que ça fonctionne il a fallu que les devs redhat (et d'autres) mettent les bouchées doubles sur les developpments de classpath et gcj. Les gars d'ooo n'ont pas fait le moindre effort, et ça on peut ne pas appécier (ça fait un peut passage en force de la part de sun): à tout moment ils vont re-péter la compatibilité.
- ce n'est pas portable (encore moins que le java de sun). eg. pas de gcj4 pour les 3 *BSD à cette heure.
- java c'est lourd et lent.
- on peut (et on est nombreux à) ne pas aimer java pour plein d'autres raisons encore, pas seulement pour les pbs du jdk sun.
>> Microsoft qui déteste la GPL et adore la BSD le prouve.
> Oui, MS c'est le mal, qu'il utilise parfois quelques lignes de BSD
Au passage, ça me rappele justement une des preuves majeures de la pertinence de la licence BSD (au moins dans certains cas).
Gageons que si les premières piles tcp/ip n'avaient pas étés vraiment libres (sous BSD, réutilisable par quiconque, propriétaire ou libre), on aurait continué d'avoir des dizaines de couches réseau différentes, majoritairement propriétaires, et toutes incompatibles entre elles. Idem pour X11 d'ailleur.
Evidement ce n'est qu'une supposition, mais elle me sert d'exemple pour montrer comment la licence BSD, parcequ'elle est moins hostile au logiciel propriétaire, peut permettre de grandes avancées dans l'interopérabilité (et ça c'est toujours profitable au logiciel libre).
Surtout que Sun c'est faire du compatible GPL tout se conservant la possibilité de faire du proprio.
La licence vers laquelle ils lorgnent (choisie pour OpenSolaris, et une rumeur la cite comme bonne candidate pour le futur de java ...) c'est la CDDL. Dont la FSF dit:
« This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the GNU GPL. That is, a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. We urge you not to use the CDDL for this reason. ».
La compatibilité GPL est tout sauf un projet de Sun. Se réserver le droit d'en tirer des binaires propriétaires à l'avenir n'est qu'une partie du problème (sans quoi la BSD révisée / MIT /ISC aurait convenu, tout en étant compatible avec la GPL et la LGPL et reconnue et acceptée par les developpeurs de LL).
La CDDL [...]. Elle est tout à fait comparable à une LGPL, ou à un dérivé BSD.
Sauf qu'elle n'est ni compatible avec la GPL (ce qui est le cas des licences LGPL et BSD révisée), ni avec la licence BSD (si ce n'est pas un pied de nez de Sun ...).
Du coup, je trouve la question du débat très mal formulée. On devrait demander: « Pourquoi Sun s'efforce d'être incompatible avec la GPL, la LGPL et la BSD ? »
Il est clair que les deux licences (LGPL et BSD) répondent aussi aux exigences formulées par Shwartz, ce dernier aurait pu les choisir au lieu de cette licence très complexe (si vous n'étes pas juristes, ne croyez pas la faq de Sun sur la CDDL !).
Le fait de ne pas choisir la GPL classique est sommes toutes assez compréhensible. La communauté du LL elle même préfère presque systèmatiquement les licences plus libres type BSD/MIT/LGPL/artistic pour les bibliothèques (Solaris contient beaucoup de biblitotheques, ce n'est pas juste un kernel, et Java c'est majoritairement des libs) et pour les interpreteurs/langages de prog (pensez à java encore): perl, python, ruby, php, gtk, libxml, libxslt, glibc, X11, openssl ... pour citer quelques incontournables.
Un système d'exploitation (eg OpenSolaris) mono-licencé sous GPL serait absolument inutilisable pour le business (et le portage de toute appli sur ce systeme, contaminerai l'appli en GPL (sympa pour les BSDistes ;). Aucune distro majeure de Linux n'est exclusivement composée de softs sous GPL d'ailleur.
Un langage de programation (eg Java) mono-licencé en GPL empecherai quasiment le developpement d'appli commerciales avec celui-ci (sans parler de l'effet sur les nombreux softs closed source tiers déjà existants et reposant sur java).
Cette dépèche manque le coche, et tombe sous l'intox savante de Shwartz : bien sûr, sun ne peut pas publier *tout* ses produits sous GPL. Le débat que Shwartz évite habilement, en réorientant la question sur l'adoption ou pas de la GPL est: pourquoi Sun a décidé de rendre ses produits incompatibles avec la GPL (et la BSD, et la LGPL au passage) ... On commence alors à deviner la position poivre et sel de Sun concernant le LL (que Shwartz appelle d'ailleur, erreur significative, le logiciel "Open Source").
Il apparait de plus en plus (cf. le blog de Shwatz) que les concurents directs de Sun sont Novel, IBM et surtout Red Hat (et non Microsoft). Rendre ses softs directement réutilisables par ces derniers (eg, si les composants du kernel Solaris étaient réutilisables dans le kernel Linux) renforcerai ses concurents au détriment de Sun.
L'essentiel de la manoeuvre de Sun consiste en une sorte d'acrobatie, pratiquer la désinformation massive au sujet des modalités d'ouverture de Solaris et Java (en faisant le plus de bruit possible: faire blogguer les employés de Sun, publier une licence ultra complexe assortie d'une faq maison, multiplier les annonces et interviews répondant aux mauvaises questions et évitant les vrais débats comme celui pour Zdnet, FUD tout azimuts sur Red Hat et la GPL etc.) pour essayer de ramener la communauté LL (qui lui a fait peut a peut perdre son principal marché, les serveurs, d'où l'urgence vitale de nous séduire pour Sun) sans aller vraiment vers elle (eg, sans avaliser ses choix de faits, en termes de licence notament) pour ne pas se faire fagociter par Red Hat et consorts.
Quand au fait de considérer la CDDL comme libre parceque reconnue par l'OSI : n'oublions pas que Sun à placé une de ses employées dans le commité de décision de l'OSI ("on purpose" !) avant l'adoption de la CDDL ...
Je confirme pour ralink: c'est le chipset « écologique » du moment.
Ralink supporte très activement la communauté FOSS (Linux, *BSD) notamment en donnant les spécifications et documentation complètes à la différence de la majorité des autres constructeurs actuels (et ils developpent eux-même le driver Linux, sous GPL). Du coup le support dans les noyaux (Linux, *BSD) évoluent très vite, et la stabilité / correction des bugs est viable sur le long terme.
Ça marche déjà très bien en pci et pcmcia (j'ai pas essayé les cartes usb), et pas seulement sous x86.
Par ailleur les ralink supportent une utilisation en mode hostap (faire un Acess Point avec son ordi) ce qui n'est pas le cas de la plupart des chipsets g du moment, notamment des chipsets intels.
Bref, d'ici quelques mois ce chipset sera au 802.11g ce que les prism 2/3 étaient au 802.11b, le choix naturel pour nous.
La moralité de ce message, c'est que des petits constructeurs peuvent se frayer un chemin face aux géants (broadcom, intel, connexant) en se batissant une bonne réputation dans la communauté FOSS.
Le problème c'est que la licence de Sun stipule que, si on a lu le(s) fichier(s) au(x)quel(s) on a contribué (cas plutôt courant ;), on n'a plus le droit de contribuer à une fonctionalité équivalente d'un logiciel tiers (un LL par ex ...).
Donc effectivement, l'appel à contribution de Sun, c'est plutôt gonflé.
>> Personellement je suis très surpris qu'ils n'aient pas au moins testé leur code sur un environement java libre
>
> J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici)
Ça marche _après_ patchage d'Ooo et ajustements de classpath etc. Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.
S'ils continuent sur cette voie, il faura repatcher tout son système à chaque mise à jour d'Ooo ? Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ? Très forts les prosélytes de java et fedora.
> Un patch ridicule.
Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner. Y compris les modifications de gcj et de classpath.
> On peut se demander si tu as lu le lien :
> "The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system"
Citation tronquée et détournée. L'ensemble du document dit qu'il faut faire comprendre aux devs java qu'ils doivent _developper_ avec une implementation libre de java sur le systeme. La paragraphe que tu cite est:
"The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately."
Ce qui n'a pas été fait.
> Avant de poster des commentaires, lisez les commentaires déjà postés.
Le fait que je n'ai pas le même avis sur toi ne doit pas te faire déduire que je n'ai pas lu les commentaires ...
En lisant le reste de mon commentaire, tu a très bien compris que j'avait lu le tien.
Même si c'est pas parfaitement portable, cela a l'avantage d'être toujours plus portable que du C/C++
Quand je disait portable, je ne parlais pas du "langage Java" mais de de la seule implementation complete qui est accessoirement l'environement nécessaire pour faire tourner Ooo (les hacks red hats ne sont encore que des hacks), à savoir l'environement Java de Sun.
Exemples: Pas de JDK 1.5 sous OpenBSD (et je crois qu'il faut de l'émul linux pour les autres BSD). Pas de JDK 1.5 pour GNU/Linux sur mips (ou autre plateforme non x86/amd64). etc. Donc oui, ça n'est pas portable, du tout. N'en déplaise aux marketeux de chez Sun.
Sur ce point on peut râler, car Sun ne permet même pas aux devs de LL de faire ces portages.
Pour reprendre ta comparaison, on trouve des compilos C et C++ pour à peu pret toutes les plateformes existantes.
Et des interpreteurs python aussi (qui, au passage, est aussi incorporé dans Ooo via PyUNO), lequel aurait été un choix moins problématique, s'ils cherchent des outils de dev rapide (et une gestion de la mémoire automatique).
Pour le moment, gcj n'est pas lui même parfaitement "portable" (mais là, j'ai confiance, ça ne tardera pas).
Pour revenir au sujet, le problème (outre toute considération technique) c'est qu'ils ont choisis la plateforme java la moins libre et la moins portable qu'ils pouvaient. Il n'est pas inutile que leurs utilsateurs leur donne un feedback pour faire savoir que ces détails ont leur importance.
[^] # Re: Quid des user-agent ?
Posté par herodiade . En réponse à la dépêche Mozilla définit la politique d'utilisation de ses marques.. Évalué à 2.
[^] # Re: CARP
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 5.4. Évalué à 3.
Tu es sûr de ça ? Si c'est le cas c'est très bonne chose !
La dernière fois que j'ai testé lvs il ne permetait pas de faire des firewall redondants faute de partage des tables d'états de netfilter (je ne parle pas des états dans la gestion des connexions interne à lvs).
[^] # Re: CARP
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 5.4. Évalué à 3.
Non, c'est un autre protocole. Inspiré des idées de hsrp, mais conçu différement et non compatible ; en particulier, quelques améliorations concernent la sécurité, notament via checksums des datagrames. Par ailleur HSRP est breveté par Cisco ce qui est plutôt génant pour certains.
CARP est avant tout basé sur le failover d'IP alors que Heartbeat est basé sur du failover applicatif, y compris IP. CARP est donc plus légé qu'Heartbeat mais plus spartiate de premier abord, le tout était de toute façon scriptable.
Il semble qu'un paradigme de CARP sous OpenBSD (en fait d'open en général amha ;) est de faire en sorte que les choses restent très carrées et propres: avec une conf simple, minimale, et pas de shell script. Pour preuve: le complément scriptable dédié au failover applicatif d'OpenBSD, ifstated, existe. Et bien que parfaitement stable, il n'est pas connecté au build, maintenu quasiment "secret" (il est dans les sources mais ne compile que si on le connais et si on ne réclame explicitement sa compilation).
# CARP
Posté par herodiade . En réponse à la dépêche Sortie de FreeBSD 5.4. Évalué à 10.
L'objectif principal est la haute disponibilité (la répartition de charge en bonus). Couplé avec d'autres outils importés d'OpenBSD (pf, pfsync) il permet notament la haute disponibilité des firewalls par redondance, repartition des tables d'états et reprise automatisée d'adresses IP.
carp:
http://www.freebsd.org/cgi/man.cgi?query=carp&apropos=0&sek(...)
pfsync:
http://www.freebsd.org/cgi/man.cgi?query=pfsync&apropos=0&s(...)
le papier de Rian McBride « Firewall Failover with pfsync and CARP »
http://www.countersiege.com/doc/pfsync-carp/(...)
[^] # Re: Alors...
Posté par herodiade . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 2.
En revanche ils se montrent très peu coopératif lorsqu'il s'agit de diffuser les spécifications de leurs chipsets (des chipsets qu'ils utilisent) et lorsque celà concerne les droits de diffusion des firmwares nécessaires à ces chipsets.
Apple choisit souvent des fournisseurs parmis les moins coopératifs (Broadcom et Ati par exemple) et refuse très souvent (malgrè une forte demande des devs noyau Linux et *BSD) de livrer les spécifications détaillées (ou de demander à ses fournisseurs de le faire, après tout Apple est là en position de force) et des licences adéquates pour la distribution des firmwares et drivers binaires.
Concernant la remontée des contributions en upstream, elle n'est parfaite pour aucun Unix (Mac OS X compris) et aucune distribution GNU/Linux. Les developpeurs "upstream" ont depuis longtemps apris à aller chercher d'eux même dans les bugtrackers et les patchsets des divers distros (et dans les ports *BSD). Ou pas.
[^] # Re: *BSD et les applications tierses
Posté par herodiade . En réponse à la dépêche PC-BSD : Un système FreeBSD pour le grand public. Évalué à 2.
Je voulais dire que le système de base n'est pas dépouillé au point d'être inutilisable en l'état, qu'il inclus beaucoup de logiciels, comme le montre le volume de leurs sources (sources qu'on peut installer ou pas mais ce n'est pas la question).
[^] # Re: drivers nvidia
Posté par herodiade . En réponse à la dépêche PC-BSD : Un système FreeBSD pour le grand public. Évalué à 3.
http://www.nvidia.com/object/freebsd_1.0-7174.html(...)
[^] # Re: *BSD et les applications tierses
Posté par herodiade . En réponse à la dépêche PC-BSD : Un système FreeBSD pour le grand public. Évalué à 2.
Enfin, minimaliste, c'est très relatif :
FreeBSD 4.9: 373M /usr/src/
OpenBSD 3.6: 590M /usr/src
Dont environ 100Mo de kernel (/usr/src/sys/) dans les deux cas. Et X.org non compris.
Pour le prix on a perl, sendmail, pop3d, un serveur kerberos, parfois apache (pour open) bien audités... bref souvent de quoi faire un serveur sans utiliser les ports/pkgsrc/packages.
[^] # Re: alors là bravo
Posté par herodiade . En réponse à la dépêche PC-BSD : Un système FreeBSD pour le grand public. Évalué à 10.
Certains apprécient la licence BSD (3 clauses, et aussi la MIT) justement parcequ'elle offre une grande très compatibilité avec les autres logiciels (elle est compatible avec la GPL -et la réciproque n'est pas vraie-, la LGPL, la MPL, avec n'importe quelle licence close source et proprio etc.).
Pour ceux-là, le fait de voir son code repris par un autre logiciel (eventuellement GPL ou propriétaire) n'est pas forcément génant (c'est plutôt une bonne chose, à minima un gage de reconnaissance).
Celà permet par exemple une large adoption d'un concept ou d'un protocole au départ developpé par un petit groupe peu influent.
Par exemples, le choix de X11 par les divers unix (propriétaires ou pas) est une très bonne chose permise par la licence à l'époque très ouverte de XFee ; idem pour la couche TCP/IP: l'implem d'origine, sous licence BSD, a permis à celle-ci de d'être adoptée aussi par les OS proprios, à une époque où les couches réseau maison en concurence étaient légions (et je suis heureux de ne pas vivre dans un monde netbeui ;) ; voir aussi, aujourd'hui, le travail de kame autour d'IPv6, ou de l'ISC avec bind, dhcpd et inn.
Quand une implémentation libre, (très) ouverte et documentée devient un standard de fait, en lieu et place de solutions propriétaires, c'est toute la communauté du libre qui en bénéficie (y compris le projet GNU). Dans ce cadre la licence BSD a toute sa place.
On peut aussi se réjouir du choix de licences permissives pour PHP, python, perl et ruby qui permet l'utilisation de ces logiciels en entreprise (eg. pour faire d'autres softs, close source). (histoire de rechauffer le tro^H^H la dépeche sur le choix de la licence de java par sun ;).
Dans le même ordre d'idées, le projet OpenBSD (dont les developpeurs maintiennent aussi OpenSSH) milite pour un internet sécurisé. Le fait que Cisco utilise maintenant le code d'OpenSSH (sous licence BSD) rend les réseaux plus sûr, et par conséquent diminue le risque d'attaques pour tout le monde (y compris les utilisateurs d'Open). Donc le choix de la licence contribue à l'objectif de sécurité (comme s'ils disaient "volez notre code, il est robuste et audité, et nous ne voulons pas que nos voisins aient la peste").
Concernant le risque de voir un projet BSD disparaitre à cause de la fermeture du code, il est plutôt théorique sur les gros projets (ormi apache et son abominable nouvelle licence). MacOSX et BSDOS n'ont pas tué FreeBSD, les developpeurs ont déserté le projet XFree lorsqu'il a changé de licence (et X.org semble bien se porter), etc. Bref, il est probable que les logiciels propriétaires utilisant du code BSD améliorent les projets BSD plus souvent qu'ils ne leur font du tort.
Pour finir, l'auteur (detenteur du copyright) d'un projet GPL peut lui aussi décider de refermer son travail. Au moins pour "ses" fichiers. Mais c'est là aussi très théorique.
[^] # Re: brevet...
Posté par herodiade . En réponse à la dépêche Sortie de GCC 4.0. Évalué à 6.
[^] # Re: java ?
Posté par herodiade . En réponse à la dépêche La sortie d'OpenOffice retardée en raison d'un manque de développeurs. Évalué à 1.
Je me suis mal exprimé. Le problème n'est pas vraiment dans le fait de citer, mais dans ta réponse, qui s'applique à une idée partielle eventuellement un passage d'un message qui dans l'ensemble peut dire autre chose (voir l'inverse); Celà permet de faire dire (et de répondre) tout et n'importe quoi. Mieux vaut répondre aux idées globales exprimées dans le message (et l'usage de la citation peut appuyer une explication dans ce cas) que, mot pour mot, à des segments de phrases (des propositions isolées).
Pas besoin de faire des disclaimers hystériques, il suffit d'un peu de bon sens (ou de bonne foi ?).
> C'est tout autant valable dans l'autre sens.
Bien sûr ; je pense même que c'est valable pour à peu près tout les unix (un logiciel posix qui n'est pas portable sous windows ou os/2 etc. n'est pas forcément sale, les environement sont trop différents).
Aussi, quand il y a un portage, la taille du patch nécéssaire est un bon indicateur à mon avis.
> Comme beaucoup de code qu'on retrouve dans BSD est en premier développé sous Linux, j'en conclus que les développements sous Linux sont majoritairement de qualités.
Non, je pense surtout que les developpeurs travaillant sous GNU/Linux sont plus nombreux. Ça ne signifie rien concernant la proportion de bon code / mauvais code.
> Comme il y a peu de transfert BSD vers Linux, j'en conclus que BSD ne fait pas grand chose.
Il y a tout de même beaucoup de transferts BSD vers Linux (et n'oublions pas que des morceaux de code BSD/MIT peuvent être inclus dans des logiciels GPL, inclusion impossible dans l'autre sens, ce qui est un avantage pour ceux qui aiment la licence BSD/MIT/ISC: elle est très "portable" ;), compatible avec beaucoup de choses, mais je dérive là ...).
Sinon je t'accorde que les contribution dans ce sens sont peut être un peu moins nombreuses que les utilisations de logiciels developpés sous Linux sous BSD (surtout si l'on parle d'environement destkop) ; mais là encore, cette remarque n'exclu pas la possibilité qu'il y ai moins de developpeurs sous BSD, mais des developpeurs très actifs et écrivant du code de qualité.
J'applique cette "mini évaluation" rapide au cas par cas (logiciel par logiciel) (et souvent assortie d'une session dans les bugtrackers pertinents).
[^] # Re: java ?
Posté par herodiade . En réponse à la dépêche La sortie d'OpenOffice retardée en raison d'un manque de développeurs. Évalué à 3.
> Tout est un upstream tocard.
Tu a bien vu, en lisant la suite de mon message, que je le sait.
Tu semble d'assez mauvaise foi sur le coup, parceque tu répond à des faits évidents en citant des bouts de phrase, et ce faisant tu masque la question de fond soulevée (ps: j'ai remarqué que tu fait ça dans presque tout tes posts polémiques).
> De tout manière votre rhétorique est connu : si c'est Red Hat qui fait le boulot alors c'est nul
> [...]
> Qui fait des efforts pour OOo à part Sun ? Pratiquement personne.
Absolument pas, c'est très bien que redhat améliore les choses.
Simplement on peut trouver, puisque c'est la question soulevée par cette dépèche, que l'absence d'efforts sur la portabilité et le choix de java _de la part d'ooo_ (pas de ton Dieu) ne rend pas forcément le projet affriolant pour le dev.
>> ça fait un peut passage en force de la part de sun
> Sun fait pratiquement tout le boulot donc ils font ce qu'ils veulent.
Oui, et gageons que dans ces conditions, ça ne changera pas facilement.
> y a-t-il OOo 2 pour les *BSD ? Non.
Typiquement, c'est une façon simple d'avoir un indice la qualité du code d'un soft. S'il est assez connu et n'est pourtant pas dans /usr/ports/ ou /usr/pkgsrc/, c'est souvent qu'il y a quelque chose de pourri dans le royaume (qualité du code, gnouteries, licence, ...).
[^] # Re: évangélisme, marketing...
Posté par herodiade . En réponse à la dépêche La sortie d'OpenOffice retardée en raison d'un manque de développeurs. Évalué à 3.
> J'entends par là que les programmeurs n'utilisent pas toujours (jamais ?)
C'est sans doute une des raisons du probleme. C'est pas forcément très sexy à priori, le developpement benevole d'une suite bureautique (surtout dans le cas d'un bloatware shooté au java).
Beaucoup moins que de jouer avec le noyau linux je pense (il semblerai que dans ce cas, à contratrio, le problème soit quasiment le surnombre des contributions !).
[^] # Re: java ?
Posté par herodiade . En réponse à la dépêche La sortie d'OpenOffice retardée en raison d'un manque de développeurs. Évalué à 4.
>Cette remarque est aujourd'hui avec gcj4 "nulle".
Sûrement pas:
- c'est intégré/fonctionel - et pour cause, joli coup de pub (hein fabb ?)- uniquement dans fedora (et encore en béta non ?).
- pour que ça fonctionne il a fallu que les devs redhat (et d'autres) mettent les bouchées doubles sur les developpments de classpath et gcj. Les gars d'ooo n'ont pas fait le moindre effort, et ça on peut ne pas appécier (ça fait un peut passage en force de la part de sun): à tout moment ils vont re-péter la compatibilité.
- ce n'est pas portable (encore moins que le java de sun). eg. pas de gcj4 pour les 3 *BSD à cette heure.
- java c'est lourd et lent.
- on peut (et on est nombreux à) ne pas aimer java pour plein d'autres raisons encore, pas seulement pour les pbs du jdk sun.
[^] # Re: vulgérisation sur les licences "libres"
Posté par herodiade . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
> Oui, MS c'est le mal, qu'il utilise parfois quelques lignes de BSD
Au passage, ça me rappele justement une des preuves majeures de la pertinence de la licence BSD (au moins dans certains cas).
Gageons que si les premières piles tcp/ip n'avaient pas étés vraiment libres (sous BSD, réutilisable par quiconque, propriétaire ou libre), on aurait continué d'avoir des dizaines de couches réseau différentes, majoritairement propriétaires, et toutes incompatibles entre elles. Idem pour X11 d'ailleur.
Evidement ce n'est qu'une supposition, mais elle me sert d'exemple pour montrer comment la licence BSD, parcequ'elle est moins hostile au logiciel propriétaire, peut permettre de grandes avancées dans l'interopérabilité (et ça c'est toujours profitable au logiciel libre).
[^] # Re: Sun : Décisions contradictoires ?
Posté par herodiade . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
Ce qui montre toujours a quel point Shwartz confond libre et open source.
[^] # Re: Pourquoi une licence *incompatible* avec la GPL ?
Posté par herodiade . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
La licence vers laquelle ils lorgnent (choisie pour OpenSolaris, et une rumeur la cite comme bonne candidate pour le futur de java ...) c'est la CDDL. Dont la FSF dit:
« This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the GNU GPL. That is, a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. We urge you not to use the CDDL for this reason. ».
(cité de http://www.fsf.org/licensing/licenses/license-list.html)(...)
La compatibilité GPL est tout sauf un projet de Sun. Se réserver le droit d'en tirer des binaires propriétaires à l'avenir n'est qu'une partie du problème (sans quoi la BSD révisée / MIT /ISC aurait convenu, tout en étant compatible avec la GPL et la LGPL et reconnue et acceptée par les developpeurs de LL).
# Pourquoi une licence *incompatible* avec la GPL ?
Posté par herodiade . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 8.
Sauf qu'elle n'est ni compatible avec la GPL (ce qui est le cas des licences LGPL et BSD révisée), ni avec la licence BSD (si ce n'est pas un pied de nez de Sun ...).
Du coup, je trouve la question du débat très mal formulée. On devrait demander: « Pourquoi Sun s'efforce d'être incompatible avec la GPL, la LGPL et la BSD ? »
Il est clair que les deux licences (LGPL et BSD) répondent aussi aux exigences formulées par Shwartz, ce dernier aurait pu les choisir au lieu de cette licence très complexe (si vous n'étes pas juristes, ne croyez pas la faq de Sun sur la CDDL !).
Le fait de ne pas choisir la GPL classique est sommes toutes assez compréhensible. La communauté du LL elle même préfère presque systèmatiquement les licences plus libres type BSD/MIT/LGPL/artistic pour les bibliothèques (Solaris contient beaucoup de biblitotheques, ce n'est pas juste un kernel, et Java c'est majoritairement des libs) et pour les interpreteurs/langages de prog (pensez à java encore): perl, python, ruby, php, gtk, libxml, libxslt, glibc, X11, openssl ... pour citer quelques incontournables.
Un système d'exploitation (eg OpenSolaris) mono-licencé sous GPL serait absolument inutilisable pour le business (et le portage de toute appli sur ce systeme, contaminerai l'appli en GPL (sympa pour les BSDistes ;). Aucune distro majeure de Linux n'est exclusivement composée de softs sous GPL d'ailleur.
Un langage de programation (eg Java) mono-licencé en GPL empecherai quasiment le developpement d'appli commerciales avec celui-ci (sans parler de l'effet sur les nombreux softs closed source tiers déjà existants et reposant sur java).
Cette dépèche manque le coche, et tombe sous l'intox savante de Shwartz : bien sûr, sun ne peut pas publier *tout* ses produits sous GPL. Le débat que Shwartz évite habilement, en réorientant la question sur l'adoption ou pas de la GPL est: pourquoi Sun a décidé de rendre ses produits incompatibles avec la GPL (et la BSD, et la LGPL au passage) ... On commence alors à deviner la position poivre et sel de Sun concernant le LL (que Shwartz appelle d'ailleur, erreur significative, le logiciel "Open Source").
Il apparait de plus en plus (cf. le blog de Shwatz) que les concurents directs de Sun sont Novel, IBM et surtout Red Hat (et non Microsoft). Rendre ses softs directement réutilisables par ces derniers (eg, si les composants du kernel Solaris étaient réutilisables dans le kernel Linux) renforcerai ses concurents au détriment de Sun.
L'essentiel de la manoeuvre de Sun consiste en une sorte d'acrobatie, pratiquer la désinformation massive au sujet des modalités d'ouverture de Solaris et Java (en faisant le plus de bruit possible: faire blogguer les employés de Sun, publier une licence ultra complexe assortie d'une faq maison, multiplier les annonces et interviews répondant aux mauvaises questions et évitant les vrais débats comme celui pour Zdnet, FUD tout azimuts sur Red Hat et la GPL etc.) pour essayer de ramener la communauté LL (qui lui a fait peut a peut perdre son principal marché, les serveurs, d'où l'urgence vitale de nous séduire pour Sun) sans aller vraiment vers elle (eg, sans avaliser ses choix de faits, en termes de licence notament) pour ne pas se faire fagociter par Red Hat et consorts.
Quand au fait de considérer la CDDL comme libre parceque reconnue par l'OSI : n'oublions pas que Sun à placé une de ses employées dans le commité de décision de l'OSI ("on purpose" !) avant l'adoption de la CDDL ...
[^] # Re: Question
Posté par herodiade . En réponse à la dépêche Ubuntu Hoary Hedgehog (5.04) est sortie. Évalué à 4.
http://www.fsf.org/resources/hw/net/wireless/cards.html(...)
[^] # Re: Question
Posté par herodiade . En réponse à la dépêche Ubuntu Hoary Hedgehog (5.04) est sortie. Évalué à 6.
Ralink supporte très activement la communauté FOSS (Linux, *BSD) notamment en donnant les spécifications et documentation complètes à la différence de la majorité des autres constructeurs actuels (et ils developpent eux-même le driver Linux, sous GPL). Du coup le support dans les noyaux (Linux, *BSD) évoluent très vite, et la stabilité / correction des bugs est viable sur le long terme.
Ça marche déjà très bien en pci et pcmcia (j'ai pas essayé les cartes usb), et pas seulement sous x86.
Par ailleur les ralink supportent une utilisation en mode hostap (faire un Acess Point avec son ordi) ce qui n'est pas le cas de la plupart des chipsets g du moment, notamment des chipsets intels.
Bref, d'ici quelques mois ce chipset sera au 802.11g ce que les prism 2/3 étaient au 802.11b, le choix naturel pour nous.
La moralité de ce message, c'est que des petits constructeurs peuvent se frayer un chemin face aux géants (broadcom, intel, connexant) en se batissant une bonne réputation dans la communauté FOSS.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à -3.
En upstream. Tu es débile ou tu fait semblant ?
[^] # Re: Mais bon sang !
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 7.
Donc effectivement, l'appel à contribution de Sun, c'est plutôt gonflé.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 2.
>
> J'ai une bonne nouvelle, ça marche déjà avec gcj (url déjà passé ici)
Ça marche _après_ patchage d'Ooo et ajustements de classpath etc. Donc je maintient, le code tel qu'ils l'ont fournis n'avait très certainement pas été testé sur des environements libres.
S'ils continuent sur cette voie, il faura repatcher tout son système à chaque mise à jour d'Ooo ? Tous passer à Fedora Core (c) et installer des versions bétas de la suite gcc ? Très forts les prosélytes de java et fedora.
> Un patch ridicule.
Je parlai de l'ensemble des modifications qu'il a fallu pour le faire tourner. Y compris les modifications de gcj et de classpath.
> On peut se demander si tu as lu le lien :
> "The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system"
Citation tronquée et détournée. L'ensemble du document dit qu'il faut faire comprendre aux devs java qu'ils doivent _developper_ avec une implementation libre de java sur le systeme. La paragraphe que tu cite est:
"The reliable way to avoid the Java Trap is to have only a free implementation of Java on your system. Then if you use a Java feature or library that free software does not yet support, you will find out straightaway, and you can rewrite that code immediately."
Ce qui n'a pas été fait.
> Avant de poster des commentaires, lisez les commentaires déjà postés.
Le fait que je n'ai pas le même avis sur toi ne doit pas te faire déduire que je n'ai pas lu les commentaires ...
En lisant le reste de mon commentaire, tu a très bien compris que j'avait lu le tien.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 2.
De mémoire, on n'a jamais vu une telle réaction pour le choix d'un autre langage dans un LL.
Maintenant les choses sont plus claires.
[^] # Re: Sun a toujours le mauvais rôle
Posté par herodiade . En réponse à la dépêche OpenOffice.org version 2.0 et Java. Évalué à 8.
Quand je disait portable, je ne parlais pas du "langage Java" mais de de la seule implementation complete qui est accessoirement l'environement nécessaire pour faire tourner Ooo (les hacks red hats ne sont encore que des hacks), à savoir l'environement Java de Sun.
Exemples: Pas de JDK 1.5 sous OpenBSD (et je crois qu'il faut de l'émul linux pour les autres BSD). Pas de JDK 1.5 pour GNU/Linux sur mips (ou autre plateforme non x86/amd64). etc. Donc oui, ça n'est pas portable, du tout. N'en déplaise aux marketeux de chez Sun.
Sur ce point on peut râler, car Sun ne permet même pas aux devs de LL de faire ces portages.
Pour reprendre ta comparaison, on trouve des compilos C et C++ pour à peu pret toutes les plateformes existantes.
Et des interpreteurs python aussi (qui, au passage, est aussi incorporé dans Ooo via PyUNO), lequel aurait été un choix moins problématique, s'ils cherchent des outils de dev rapide (et une gestion de la mémoire automatique).
Pour le moment, gcj n'est pas lui même parfaitement "portable" (mais là, j'ai confiance, ça ne tardera pas).
Pour revenir au sujet, le problème (outre toute considération technique) c'est qu'ils ont choisis la plateforme java la moins libre et la moins portable qu'ils pouvaient. Il n'est pas inutile que leurs utilsateurs leur donne un feedback pour faire savoir que ces détails ont leur importance.