Pas libre si tu veux en faire le commerce ou l'utiliser pour faire du commerce. Par contre dans des domaines comme l'éducation (utilisation par des universités par exemple), la licence est plus libre.
Quand on parle de logiciel libre, on parle de logiciel libre tels que définis par GNU (définition reprise par Debian, définition reprise et modifiée dans ses termes par l'Open Source Initiative).
Bien entendu, il s'agit d'une définition arbitraire. Ce n'est pas parce qu'une chose n'est pas un logiciel libre qui ne fourni aucune liberté, que c'est une mauvaise chose. Ca signifie juste qu'il n'est pas conforme à la définition du logiciel libre, ça signifie qu'il ne remplit par les conditions nécessaires pour s'y conformer.
Pour un logiciel, selon les acteurs du libre (dont je fais partie), c'est problématique qu'un logiciel ne soit pas conforme à cette définition.
(+3) : message A
|--- (- 2) : message B
|-------(+7) : message C
Eh les gens, si le message B est si inutile, alors c'est un troll, du spam ou une remarque débile. En toute logique y répondre n'a aucun intéret (ben oui aucune question utile n'y est soulevée et aucune réponse utile n'est donnée) donc le message C est également inutile. Cela devrait occasionner au plus des messages privés.
Alors voila quelqu'un pense que le libre ne peut se soucier que du non commercial et que donc cette licence peut suffire pour du libre. Ce n'est pas mon avis et ce n'est pas celui de la majorité des gens sur ce site, mais je ne vois pas comment on peut dire que l'expression de cet avis est inutile.
Tu as juste le droit de voir, rien d'autre.
En gros, ca casse le mythe "code pouvant contenir des chevaux de Troie", mais rien de plus sur l'utilisabilité/deployabilité etc... En gros, on tem et un gros gateau qui sent très bon (euh... Et encore, j'ai des doutes :), meme si il y a du bon dans les produits MS... ), et on te dit "pas touche, regarde"
En gros, ca casse le mythe "code pouvant contenir des chevaux de Troie
Même pas: de toutes manières il est presque évident que les éventuels troyens auraient été ajoutés juste avant le build pour que le moins possible de gens les voient.
C'est pas parce que ta main droite est vide que t'a pas les clefs de la maison.
Dans ce cas, ne faitre aucunement confiance non plus au moindre binaire pré-compilé disponible sur les istes web...
Allez, on vire les rpm et tout ce bordel sur tous les sites ;-)
Dans ce cas, ne faitre aucunement confiance non plus au moindre binaire pré-compilé disponible sur les istes web...
Exactement ! Gentoo rox !
Plus sérieusement, je ne conait pas l'organisation interne de redhat, mais je pense qu'il est plus facile pour un développeur Redhat de se renseigner sur les conditions de build d'un paquet que pour un dévelopeur microsoft (à ce que j'ai cru comprendre il n'ont souvent même pas accès au code des autres services, genre les gars d'IE peuvent pas lire le code du kernel).
Cela parait logique. Je ne sais pas si c'est vrai, mais ça parait sacrément logique.
Dans la logique propriétaire, il faut cacher le code. Plus de personnes le connaissent plus le risque de fuite est grand. Donc il est cohérent que les gens ne sachent que ce dont ils ont strictement besoin.
Évidemment, ça implique un grand risque de réinvention de la roue, puisqu'ils ne peuvent pas s'inspirer du reste du code, ça implique un risque d'erreur du fait d'une absence de compréhension du reste du code.
Mais ce sont des problèmes bien connus du modèle propriétaire.
Évidemment, ça implique un grand risque de réinvention de la roue, puisqu'ils ne peuvent pas s'inspirer du reste du code, ça implique un risque d'erreur du fait d'une absence de compréhension du reste du code.
Je vois pas la logique, t'as pas besoin d'acces au code pour utiliser une librairie preexistante.
Ca n'a rien a voir avec la logique proprietaire d'ailleurs, je me suis jamais amuse a regarder le code de la libc quand je programmes sous Linux, la doc me suffit amplement.
gnap gnap dit « s'inspirer du code », pas « utiliser la bibliothèque ».
Par exemple, il arrive que l'on ait besoin de faire deux choses à la fois et que l'une de ces choses soit déjà très bien faite par une fonction déjà existante, disons que l'on aurait besoin de faire une manipulation sur chaque structure S pendant que l'on trie un tableau de S et que l'on ne [vp]eut pas faire la manipulation après le tri. Des fonctions de tri bien écrites et optimisées pour le langage que l'on utilise, c'est quand même plus facile de s'en inspirer que de les réécrire.
De la même façon, on peut s'inspirer du code des itérateurs pour écrire ceux de sa structure à soi, etc.
Tu vas me dire que l'on trouve tout cela dans les bouquins ou sur le net, mais, entre autres, le code utilisé dans les autres modules est, justement, utilisé, contrairement à celui des bouquins qui est souvent pédagogique, générique ou inadapté au langage que l'on veut/doit utiliser.
Par exemple, il arrive que l'on ait besoin de faire deux choses à la fois et que l'une de ces choses soit déjà très bien faite par une fonction déjà existante, disons que l'on aurait besoin de faire une manipulation sur chaque structure S pendant que l'on trie un tableau de S et que l'on ne [vp]eut pas faire la manipulation après le tri. Des fonctions de tri bien écrites et optimisées pour le langage que l'on utilise, c'est quand même plus facile de s'en inspirer que de les réécrire.
Tu imagines bien que l'on a des librairies accessible a tout le monde pour ce genre de choses voyons.
De la même façon, on peut s'inspirer du code des itérateurs pour écrire ceux de sa structure à soi, etc.
Ca tombe bien, la STL c'est des templates, code accessible a tout le monde, toi y compris.
1. Je vais numéroter les idées puisque, sinon, le contradicteur en profite toujours pour « oublier » l'idée principale et s'attaquer à des détails des idées secondaires.
2. Tu ne réagis pas sur la disctinction inspirer - utiliser.
3. Je donne des exemples simples, compréhensibles par tous, pour ne pas entrer dans des détails qui pourraient être spécifiques et à partir desquels tout à chacun peut imaginer d'autres exemples plus précis. Ces exemples sont donc génériques et les fonctions envisagées sont effectivement certainement rencontrables facilement ailleurs (c'est pour cela que j'ai parlé des bouquins et d'internet).
4. Tu fais bien de parler de la STL : il faut avoir lu son code pour savoir que, avec un itérateur i, il est plus rapide de faire ++i que i++...
5. Et puis la STL, ce sont des templates, donc le code est dans le prototype, donc dans les .h. Mais toute bibliothèque n'est pas une bibliothèque de templates et les prototypes ne sont pas :
- forcément lisibles (merci les macros) ;
- forcément plus intéressants que la doc dont tu faisais mention et qui peut d'ailleurs donner des indications sur la mise en ½uvre.
6. Savoir comment un problème a été résolu ailleurs permet :
- de donner des pistes pour résoudre un problème similaire ;
- de rester cohérent dans la façon dont sont traités les problèmes similaires.
7. Ce n'est pas parce qu'il y a des cas où avoir accès au code n'est pas nécessaire qu'il n'y a pas de cas où cela peut être utile.
Tu ne réagis pas sur la disctinction inspirer - utiliser.
C'est pourtant tres simple, si les gens ont des questions sur une partie du code, ils demandent au developpeur, sur une liste de distribution, ... et ils ont la reponse. C'est pas un probleme, des questions du genre "comment est-ce que X fait Y dans la librairie, j'ai un probleme similaire" j'en vois de temps en temps sur les listes, et les reponses reviennent en retour.
Mais toute bibliothèque n'est pas une bibliothèque de templates et les prototypes ne sont pas :
- forcément lisibles (merci les macros) ;
- forcément plus intéressants que la doc dont tu faisais mention et qui peut d'ailleurs donner des indications sur la mise en ½uvre.
Ben oui, mais de mon point de vue personnel, si tu as besoin de lire le code source de la librairie pour l'utiliser, tu fonces dans le mur, car tu finiras par utiliser un comportement que tu as vu dans les sources, qui n'est pas forcement documente, et qui donc peut changer a tout moment, bref, ton soft risque de planter un jour car tu te bases sur le code et non la doc.
Savoir comment un problème a été résolu ailleurs permet :
- de donner des pistes pour résoudre un problème similaire ;
- de rester cohérent dans la façon dont sont traités les problèmes similaires.
Oui, mais avoir les sources n'est pas la seule methode pour resoudre ce probleme.
Ce n'est pas parce qu'il y a des cas où avoir accès au code n'est pas nécessaire qu'il n'y a pas de cas où cela peut être utile.
Je vois pas la logique, t'as pas besoin d'acces au code pour utiliser une librairie preexistante.
Je ne pense pas que le programeur lambda pense à encapsuler les plus génériques de ses fonctions dans une bibliothèque, et surtout à les documenter et maintenir correctement. Surtout que ça impliquerais un nombre énorme de bibliothèque toutes plus ou moins bien maintenues.
Avec le copier/coller tu fait un "micro fork" qui te permet d'adapter et maintenir toi même le morceau de code. Ça te permet de réemployer sans trop de risques même du code d'un projet qui risque de mourrir demain.
Je ne pense pas que le programeur lambda pense à encapsuler les plus génériques de ses fonctions dans une bibliothèque, et surtout à les documenter et maintenir correctement. Surtout que ça impliquerais un nombre énorme de bibliothèque toutes plus ou moins bien maintenues.
Les fonctions vraiment generiques de base, un programmeur sait les implementer lui-meme, si elles sont un peu plus complexes, alors elles ont de bonnes chances de se retrouver dans une librairie, car apres tout, le developpeur va devoir lui-meme les reutiliser dans son projet. Les gens se plaignent de la myriade de dlls dans Windows, il y a une raison...
Avec le copier/coller tu fait un "micro fork" qui te permet d'adapter et maintenir toi même le morceau de code. Ça te permet de réemployer sans trop de risques même du code d'un projet qui risque de mourrir demain.
Oui, et tu te retrouves avec 150 occurences du meme code sur la machine, et si le code a un trou de securite tu te retrouves avec 150 parties de code a patcher plutot qu'une... Je t'expliques pas comme c'est simple de retrouver ce genre de choses pour avertir les developpeurs qu'il y a une faille dans leur code en plus.
mais je pense qu'il est plus facile pour un développeur Redhat de se renseigner sur les conditions de build d'un paquet que pour un dévelopeur microsoft
Perdu.
On a acces a tout ce qui permet de builder, pour la simple et bonne raison qu'on a besoin de savoir comment ca fonctionne pour faire notre boulot, certains on besoin de connaitre comment la localisation marche, d'autres le rebasement des binaires, etc... Bref, tout est dispo.
Cela sans parler du fait que les gens qui font les builds sont des employes comme les autres, pas forcement americains, qui ne passent pas forcement leur vie dans ce team, avec leurs bureaux a quelques pas des notres.
Bref, les idees de complot de ce genre me feront toujours marrer, en theorie c'est bien joli, en realite c'est a peu pres impossible a faire sans que cela se sache publiquement vu le nombre de gens capables de se rendre compte de la chose.
je me doute bien que tu as accès à un exemplaire utilisable du système de build, sinon ça serait pas jouable. Mais là je parlais de l'instance de celui-ci qui compile le code qui va sur les CDs/sur windowsupdate. Tu y a accès ?
Mais là je parlais de l'instance de celui-ci qui compile le code qui va sur les CDs/sur windowsupdate. Tu y a accès ?
Mais c'est de cela dont je te parles, on a un build team qui s'occupe de builder les binaires, les gens de ce build team sont des employes comme les autres, qui changent de team de temps en temps, avec des employes d'autres teams qui les rejoignent, etc... On mange a la cafeteria avec eux, on les voit dans les meetings, en soiree, ... C'est pas des agents secrets payes par le FBI.
De plus, notre code va au travers, les testeurs, qui connaissent le code, testent le code qui en sort, quand un testeur ou un client reporte un probleme c'est ces binaires la qu'on debugge, tu imagines bien que l'on remarquera tres rapidement si le code qu'on voit dans le debugger n'a rien a voir avec ce qu'on a ecrit.
Je veut bien admettre que tu est sincère (même si faire confiance au build parce que tu croise les gars, quand on en est à discutter de savoir si le compilo peut contenir la backdoor, c'est un peu excessif). En fait c'est parce que Microsoft a pleins d'autre moyens de faire executer du code à une machine distante, sans passer par un mécanisme dédié qui serait caché des développeurs.
Ni au moindre sources dont vous n'etes pas sûr quel ne contient pas un troyen ou un exploit...
Y'a une diffèrence entre une faille de sécurité quelconque, blocable, détectable et correctible par les techniques ordinaires, et une backdoor réellement planquée.
La première, si elle n'arrive pas souvent, peut passer pour une typo (pas trop souvent, cf wuftpd que plus personne n'utilise). La seconde c'est plus chaud. Surtout que des équipes (comme celle d'OpenBSD) auditent le code d'un certain nombre de logiciels libres, de temps à autres.
Un moyen de limiter les risque étant de bootstrapper les compilations de compilo avec d'autres compilos...
Le problème c'est que bien souvent un compilo n'est prévu pour être compilé qu'avec lui même, et que quand ils ne sont pas libre c'est assez dur de les recompiler :)
Ni à aucun binaire qui n'a pas été compilé par vos soins, fut-il gcc. Et compiler un compilateur sans compilateur, c'est coton.
Si, il suffirait (par exemple) de compiler apache 2.0 avec GCC 2.x. La probabilité pour que le compilateur puisse injecter des failles dans des logiciels crées des années plus tard est assez faible (pas dit qu'apache2 compile bien avec gcc 2.x, mais ça doit pouvoir se faire).
Mais ça c'est en supposant qu'on se retrouve avec un GCC tombé du ciel. En pratique il est issu d'une collaboration de gourous, dont certains de la FSF, qui auraient probablement eu du mal à admettre qu'on vienne trojaniser leur jouet. Surtout qu'un moteur qui vient injecter des modification complexes dans certains programes particuliers ça doit pas être discret. Ou alors c'est un complot, mais si tu va par là rien ne te prouve que ta famille existe.
Au contraire, le système de build de microsoft est sous contrôle d'une seule entité, et pas forcément connue pour son idéalisme.
La seule chose c'est que tu a une distribution qui compile les sources.
La distribution c'est donc un partenaire de confiance.
C'est sûr que si tu va télécharger (et installe) une distribution polonaise créés par des tchèques sortant d'un meeting de "c'est moi qui pirate le plus fort" en russie, t'es pas sûr du tout de sa non présence de trojans et autres choses.
D'ou l'interet d'avoir plusieurs distributions. Ubuntu par exemple n'a pas le même binaire que Redhat (au sens 2 compilations différentes chaqu'un de son côté).
La seule chose avec Microsoft, c'est que tu n'a pas ça !
Si tu n'a pas confiance en Microsoft, et que tu croit que tes produits sont vérolés, et qu'ils te fileraient une version du code source sans les malwares, et bien tu reste chez Microsoft POINT, tu n'a pas d'autre possibilité d'avoir accès à MS Office ou MS Windows.
La seule chose c'est que tu a une distribution qui compile les sources.
La distribution c'est donc un partenaire de confiance.
Ah, parce que ta distribution t'affiche les sources et t'oblige à les relires avant de les compiler... :o)
Même avec Gentoo, ce genre de scénario est possible... Qu'est ce qui te prouve que l'ebuild va chercher les sources au bon endroit, ou même que le cheval de troie n'a pas été placé là par l'auteur du logiciel.
Pour Gentoo même si c'est toi qui compile, Gentoo c'est un partenaire de confiance, tu fait confiance à Gentoo pour qu'ils te mettent pas une mauvaise URL des sources.
# loin
Posté par olosta . Évalué à 4.
On a même pas la "liberté 0" : le droit d'utiliser le logiciel pour n'importe quel utilisation.
[^] # Re: loin
Posté par Matthieu . Évalué à -3.
Pas libre si tu veux en faire le commerce ou l'utiliser pour faire du commerce. Par contre dans des domaines comme l'éducation (utilisation par des universités par exemple), la licence est plus libre.
C'est ce que j'en comprend.
[^] # Re: loin
Posté par olosta . Évalué à 8.
Oui mais, ça c'est pas libre, point.
http://fr.wikipedia.org/wiki/Logiciel_libre
http://www.gnu.org/philosophy/free-sw.fr.html (liberté 0)
http://www.opensource.org/docs/definition.php (point 6)
presque la même chose mais en français : http://www.debian.org/social_contract#guidelines (point 6)
[^] # Re: loin
Posté par Anonyme . Évalué à 4.
Quand on parle de logiciel libre, on parle de logiciel libre tels que définis par GNU (définition reprise par Debian, définition reprise et modifiée dans ses termes par l'Open Source Initiative).
Bien entendu, il s'agit d'une définition arbitraire. Ce n'est pas parce qu'une chose n'est pas un logiciel libre qui ne fourni aucune liberté, que c'est une mauvaise chose. Ca signifie juste qu'il n'est pas conforme à la définition du logiciel libre, ça signifie qu'il ne remplit par les conditions nécessaires pour s'y conformer.
Pour un logiciel, selon les acteurs du libre (dont je fais partie), c'est problématique qu'un logiciel ne soit pas conforme à cette définition.
[^] # Re: loin
Posté par andeus . Évalué à 3.
[^] # Re: loin
Posté par Matthieu . Évalué à 0.
[^] # Re: loin
Posté par olosta . Évalué à 2.
(+3) : message A
|--- (- 2) : message B
|-------(+7) : message C
Eh les gens, si le message B est si inutile, alors c'est un troll, du spam ou une remarque débile. En toute logique y répondre n'a aucun intéret (ben oui aucune question utile n'y est soulevée et aucune réponse utile n'est donnée) donc le message C est également inutile. Cela devrait occasionner au plus des messages privés.
Alors voila quelqu'un pense que le libre ne peut se soucier que du non commercial et que donc cette licence peut suffire pour du libre. Ce n'est pas mon avis et ce n'est pas celui de la majorité des gens sur ce site, mais je ne vois pas comment on peut dire que l'expression de cet avis est inutile.
[^] # Re: loin
Posté par Matthieu . Évalué à 2.
Et en plus je ne pense pas, je me demande si (cette licence ne serait pas un peu libre si on l'utilise dans un cadre non-commercial).
# Libre regard du code source, POINT.
Posté par Zenitram (site web personnel) . Évalué à 3.
En gros, ca casse le mythe "code pouvant contenir des chevaux de Troie", mais rien de plus sur l'utilisabilité/deployabilité etc... En gros, on tem et un gros gateau qui sent très bon (euh... Et encore, j'ai des doutes :), meme si il y a du bon dans les produits MS... ), et on te dit "pas touche, regarde"
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 8.
C'est pas parce que ta main droite est vide que t'a pas les clefs de la maison.
[^] # Re: Libre regard du code source, POINT.
Posté par Zenitram (site web personnel) . Évalué à 4.
Allez, on vire les rpm et tout ce bordel sur tous les sites ;-)
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 2.
Plus sérieusement, je ne conait pas l'organisation interne de redhat, mais je pense qu'il est plus facile pour un développeur Redhat de se renseigner sur les conditions de build d'un paquet que pour un dévelopeur microsoft (à ce que j'ai cru comprendre il n'ont souvent même pas accès au code des autres services, genre les gars d'IE peuvent pas lire le code du kernel).
[^] # Re: Libre regard du code source, POINT.
Posté par Anonyme . Évalué à 3.
Dans la logique propriétaire, il faut cacher le code. Plus de personnes le connaissent plus le risque de fuite est grand. Donc il est cohérent que les gens ne sachent que ce dont ils ont strictement besoin.
Évidemment, ça implique un grand risque de réinvention de la roue, puisqu'ils ne peuvent pas s'inspirer du reste du code, ça implique un risque d'erreur du fait d'une absence de compréhension du reste du code.
Mais ce sont des problèmes bien connus du modèle propriétaire.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 2.
Je vois pas la logique, t'as pas besoin d'acces au code pour utiliser une librairie preexistante.
Ca n'a rien a voir avec la logique proprietaire d'ailleurs, je me suis jamais amuse a regarder le code de la libc quand je programmes sous Linux, la doc me suffit amplement.
[^] # Re: Libre regard du code source, POINT.
Posté par Sylvain Sauvage . Évalué à 4.
Par exemple, il arrive que l'on ait besoin de faire deux choses à la fois et que l'une de ces choses soit déjà très bien faite par une fonction déjà existante, disons que l'on aurait besoin de faire une manipulation sur chaque structure S pendant que l'on trie un tableau de S et que l'on ne [vp]eut pas faire la manipulation après le tri. Des fonctions de tri bien écrites et optimisées pour le langage que l'on utilise, c'est quand même plus facile de s'en inspirer que de les réécrire.
De la même façon, on peut s'inspirer du code des itérateurs pour écrire ceux de sa structure à soi, etc.
Tu vas me dire que l'on trouve tout cela dans les bouquins ou sur le net, mais, entre autres, le code utilisé dans les autres modules est, justement, utilisé, contrairement à celui des bouquins qui est souvent pédagogique, générique ou inadapté au langage que l'on veut/doit utiliser.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 0.
Tu imagines bien que l'on a des librairies accessible a tout le monde pour ce genre de choses voyons.
De la même façon, on peut s'inspirer du code des itérateurs pour écrire ceux de sa structure à soi, etc.
Ca tombe bien, la STL c'est des templates, code accessible a tout le monde, toi y compris.
[^] # Re: Libre regard du code source, POINT.
Posté par Sylvain Sauvage . Évalué à 3.
2. Tu ne réagis pas sur la disctinction inspirer - utiliser.
3. Je donne des exemples simples, compréhensibles par tous, pour ne pas entrer dans des détails qui pourraient être spécifiques et à partir desquels tout à chacun peut imaginer d'autres exemples plus précis. Ces exemples sont donc génériques et les fonctions envisagées sont effectivement certainement rencontrables facilement ailleurs (c'est pour cela que j'ai parlé des bouquins et d'internet).
4. Tu fais bien de parler de la STL : il faut avoir lu son code pour savoir que, avec un itérateur i, il est plus rapide de faire ++i que i++...
5. Et puis la STL, ce sont des templates, donc le code est dans le prototype, donc dans les .h. Mais toute bibliothèque n'est pas une bibliothèque de templates et les prototypes ne sont pas :
- forcément lisibles (merci les macros) ;
- forcément plus intéressants que la doc dont tu faisais mention et qui peut d'ailleurs donner des indications sur la mise en ½uvre.
6. Savoir comment un problème a été résolu ailleurs permet :
- de donner des pistes pour résoudre un problème similaire ;
- de rester cohérent dans la façon dont sont traités les problèmes similaires.
7. Ce n'est pas parce qu'il y a des cas où avoir accès au code n'est pas nécessaire qu'il n'y a pas de cas où cela peut être utile.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 1.
C'est pourtant tres simple, si les gens ont des questions sur une partie du code, ils demandent au developpeur, sur une liste de distribution, ... et ils ont la reponse. C'est pas un probleme, des questions du genre "comment est-ce que X fait Y dans la librairie, j'ai un probleme similaire" j'en vois de temps en temps sur les listes, et les reponses reviennent en retour.
Mais toute bibliothèque n'est pas une bibliothèque de templates et les prototypes ne sont pas :
- forcément lisibles (merci les macros) ;
- forcément plus intéressants que la doc dont tu faisais mention et qui peut d'ailleurs donner des indications sur la mise en ½uvre.
Ben oui, mais de mon point de vue personnel, si tu as besoin de lire le code source de la librairie pour l'utiliser, tu fonces dans le mur, car tu finiras par utiliser un comportement que tu as vu dans les sources, qui n'est pas forcement documente, et qui donc peut changer a tout moment, bref, ton soft risque de planter un jour car tu te bases sur le code et non la doc.
Savoir comment un problème a été résolu ailleurs permet :
- de donner des pistes pour résoudre un problème similaire ;
- de rester cohérent dans la façon dont sont traités les problèmes similaires.
Oui, mais avoir les sources n'est pas la seule methode pour resoudre ce probleme.
Ce n'est pas parce qu'il y a des cas où avoir accès au code n'est pas nécessaire qu'il n'y a pas de cas où cela peut être utile.
Tout a fait d'accord
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 2.
Avec le copier/coller tu fait un "micro fork" qui te permet d'adapter et maintenir toi même le morceau de code. Ça te permet de réemployer sans trop de risques même du code d'un projet qui risque de mourrir demain.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 0.
Les fonctions vraiment generiques de base, un programmeur sait les implementer lui-meme, si elles sont un peu plus complexes, alors elles ont de bonnes chances de se retrouver dans une librairie, car apres tout, le developpeur va devoir lui-meme les reutiliser dans son projet. Les gens se plaignent de la myriade de dlls dans Windows, il y a une raison...
Avec le copier/coller tu fait un "micro fork" qui te permet d'adapter et maintenir toi même le morceau de code. Ça te permet de réemployer sans trop de risques même du code d'un projet qui risque de mourrir demain.
Oui, et tu te retrouves avec 150 occurences du meme code sur la machine, et si le code a un trou de securite tu te retrouves avec 150 parties de code a patcher plutot qu'une... Je t'expliques pas comme c'est simple de retrouver ce genre de choses pour avertir les developpeurs qu'il y a une faille dans leur code en plus.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 2.
Perdu.
On a acces a tout ce qui permet de builder, pour la simple et bonne raison qu'on a besoin de savoir comment ca fonctionne pour faire notre boulot, certains on besoin de connaitre comment la localisation marche, d'autres le rebasement des binaires, etc... Bref, tout est dispo.
Cela sans parler du fait que les gens qui font les builds sont des employes comme les autres, pas forcement americains, qui ne passent pas forcement leur vie dans ce team, avec leurs bureaux a quelques pas des notres.
Bref, les idees de complot de ce genre me feront toujours marrer, en theorie c'est bien joli, en realite c'est a peu pres impossible a faire sans que cela se sache publiquement vu le nombre de gens capables de se rendre compte de la chose.
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: Libre regard du code source, POINT.
Posté par pasBill pasGates . Évalué à 2.
Mais c'est de cela dont je te parles, on a un build team qui s'occupe de builder les binaires, les gens de ce build team sont des employes comme les autres, qui changent de team de temps en temps, avec des employes d'autres teams qui les rejoignent, etc... On mange a la cafeteria avec eux, on les voit dans les meetings, en soiree, ... C'est pas des agents secrets payes par le FBI.
De plus, notre code va au travers, les testeurs, qui connaissent le code, testent le code qui en sort, quand un testeur ou un client reporte un probleme c'est ces binaires la qu'on debugge, tu imagines bien que l'on remarquera tres rapidement si le code qu'on voit dans le debugger n'a rien a voir avec ce qu'on a ecrit.
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: Libre regard du code source, POINT.
Posté par Larry Cow . Évalué à 3.
Ni à aucun binaire qui n'a pas été compilé par vos soins, fut-il gcc. Et compiler un compilateur sans compilateur, c'est coton.
[^] # Re: Libre regard du code source, POINT.
Posté par M . Évalué à 2.
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 3.
La première, si elle n'arrive pas souvent, peut passer pour une typo (pas trop souvent, cf wuftpd que plus personne n'utilise). La seconde c'est plus chaud. Surtout que des équipes (comme celle d'OpenBSD) auditent le code d'un certain nombre de logiciels libres, de temps à autres.
[^] # Re: Libre regard du code source, POINT.
Posté par Guillaume Knispel . Évalué à 2.
Le problème c'est que bien souvent un compilo n'est prévu pour être compilé qu'avec lui même, et que quand ils ne sont pas libre c'est assez dur de les recompiler :)
[^] # Re: Libre regard du code source, POINT.
Posté par un_brice (site web personnel) . Évalué à 2.
Mais ça c'est en supposant qu'on se retrouve avec un GCC tombé du ciel. En pratique il est issu d'une collaboration de gourous, dont certains de la FSF, qui auraient probablement eu du mal à admettre qu'on vienne trojaniser leur jouet. Surtout qu'un moteur qui vient injecter des modification complexes dans certains programes particuliers ça doit pas être discret. Ou alors c'est un complot, mais si tu va par là rien ne te prouve que ta famille existe.
Au contraire, le système de build de microsoft est sous contrôle d'une seule entité, et pas forcément connue pour son idéalisme.
[^] # Re: Libre regard du code source, POINT.
Posté par alexissoft . Évalué à 1.
La distribution c'est donc un partenaire de confiance.
C'est sûr que si tu va télécharger (et installe) une distribution polonaise créés par des tchèques sortant d'un meeting de "c'est moi qui pirate le plus fort" en russie, t'es pas sûr du tout de sa non présence de trojans et autres choses.
D'ou l'interet d'avoir plusieurs distributions. Ubuntu par exemple n'a pas le même binaire que Redhat (au sens 2 compilations différentes chaqu'un de son côté).
La seule chose avec Microsoft, c'est que tu n'a pas ça !
Si tu n'a pas confiance en Microsoft, et que tu croit que tes produits sont vérolés, et qu'ils te fileraient une version du code source sans les malwares, et bien tu reste chez Microsoft POINT, tu n'a pas d'autre possibilité d'avoir accès à MS Office ou MS Windows.
Voila :)
[^] # Re: Libre regard du code source, POINT.
Posté par neriki (site web personnel) . Évalué à 1.
Ah, parce que ta distribution t'affiche les sources et t'oblige à les relires avant de les compiler... :o)
Même avec Gentoo, ce genre de scénario est possible... Qu'est ce qui te prouve que l'ebuild va chercher les sources au bon endroit, ou même que le cheval de troie n'a pas été placé là par l'auteur du logiciel.
[^] # Re: Libre regard du code source, POINT.
Posté par alexissoft . Évalué à 2.
[^] # Re: Libre regard du code source, POINT.
Posté par neriki (site web personnel) . Évalué à 2.
A ce propos, je vous propose de lire Reflections on Trusting Trust de Kenneth Thompson, l'un des concepteurs d'Unix.
http://cm.bell-labs.com/who/ken/trust.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.