Bah, c'est juste une info, en plus Minix est un système UnixLike libre facilement étudiable, d'une conception fort interressante (microkernel strict, objectif de sécurité et stabilité, ...)
S'il faillait ne pas parler de tous les projets des gens qui ont eu une flamewar avec Linus un jour ou l'autre.... :) En plus ils ne sont même pas particulièrement ennemis.
puisque seule une licence permet de donner des libertés qui ne sont pas prévues par le droit d'auteur.
Les libertés de faire quoi ? De le garder pour soit et de travailler soit-même dessus, parce qu'on à juste pas envi de le distribuer ?
J'en ai marre (+ pas le temps) d'essayer de raisonner dans le vide et de me heurter à des personnes qui pensent tout savoir (<ironie>alors qu'il est bien évident que c'est faux puisque c'est forcement moi qui sait tout ;))</ironie> <= j'espère qu'avec les balises et le smiley tout le monde comprendra) alors je vais faire de gros copiés-collés de la FSF (ce à quoi ce qui veulent à tout prix se raccrocher au seul défaut identifiable d'Ubuntu en l'érigeant en une grave atteinte philosopique du LL s'empresseront de me rétorque que la FSF n'est pas la seule autorité, argument que je m'empresserais d'ignorer)
http://www.gnu.org/philosophy/categories.fr.html#TOCPrivateS(...) Logiciel privé
Les logiciels privés sont développés pour un utilisateur (typiquement pour une organisation ou une société). Cet utilisateur le garde et ne publie ni les fichiers sources ni les fichiers binaires.
Un programme privé est dans un certain sens un logiciel libre si son seul utilisateur a tous les droits dessus. Cependant, en y réfléchissant un peu, cela n'a pas vraiment de sens de se poser la question de savoir si un tel programme est un logiciel libre ou non.
En général, nous ne pensons pas qu'il soit mauvais de développer un programme et de ne pas le publier. Il y a des fois où un programme est si utile que le garder pour soi est égoïste. Toutefois, la plupart des programmes ne sont pas si merveilleux que ça, et les garder pour soi n'est pas particulièrement dommageable. Donc, le développement de logiciel pour un usage privé, qui représente une grande part de l'emploi dans la programmation, ne viole pas les principes du mouvement du logiciel libre.
Pratiquement tous les emplois de programmeurs se situent dans le développement de logiciels privés; par conséquent la plupart des emplois de programmeurs sont, ou pourraient être faits d'une manière compatible avec le mouvement du logiciel libre.
Donc voilà le truc d'Ubuntu est clairement un logiciel privé, et on peut estimer que c'est dommage qu'il ne soit pas distribué et que la non distribution fait du tord à l'image d'Ubuntu, mais ça n'en fait pas un logiciel propriétaire pour autant, et on ne peut pas accuser Ubuntu d'être un éditeur de logiciel propriétaire. Pas plus que le fait d'être un logiciel commercial ne rend un logiciel libre ou propriétaire http://www.gnu.org/philosophy/categories.fr.html#TOCcommerci(...)
Même dans la GPL il n'y a pas d'obligation de distribuer, et on peut de plus très bien mélanger en toute tranquilité chez soit un logiciel sous GPL et un autre avec une licence parfaitement "incompatible" (mais qui elle aussi n'interdit pas le mélange en question en ne régisseant que la distribution et en laissant toute libertée d'effectuer des modifications) tant qu'on ne redistribue pas le tout. On peut même déployer le tout dans l'intégralité d'une entreprise si le developpement à été fait à l'intérieur de cette entreprise, quand bien même il s'agirait d'une multinationnale de 1 millions d'employés. Je ne suis pas pas sûr qu'une obligation de diffusion permette à un logiciel d'être libre.
Ça n'a pas à tenir ou à ne pas tenir la route ; le truc de Canonical n'est pas distribué alors que le truc de SuSE oui. Canonical n'a pas pas besoin "d'escuse"
J'ai du mal à comprendre pourquoi autant de monde croit que c'est du proprio, alors que sous toutes les définitions que vous prenez ça n'en est évidemment pas... Et ce n'est pas la phrase "les source ne sont pas disponibles" qui devrait faire penser le contraire, même si apparement elle le fait chez les personnes qui connaissent peut les bases légales et idéologiques du LL.
Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Ça n'a rien d'idiot ni de militant. C'est répondre à un besoin de manière efficace en gardant un code sain et non rempli de wrappers et autres choses dédiées uniquement à la compatibilité, chose que le nombre subliminal de developpeur empeche de toute façon de faire. Ça ne gène surtout pas les développeurs utilisateurs (qu'est-ce qu'il en aurait à foutre de la compatibilité binaire ? ils passent de toute manière leur journée à faire tourner GCC et se basent de toute manière toujours sur les dernières versions et ils ont raison), en rien les utilisateurs finaux (qui utilisent soit une version packagée sur leur distri ou sur un liveCD (ou d7) ou alors un binaire statique dans le "pire" des cas).
Encore une fois on ne change pas pour le plaisir, et pour rassurer ceux qui ont la critique stérile facile (manque de compétence, idiotie ???(en même temps jusqu'à présent j'ai ni concu l'archi ni pris de décision de casser la compatibilité binaire, donc finalement je suis pas si visé que ça)) l'archi est suffisement bien faites pour qu'en réalité l'ABI ne change qu'avec l'API, sauf réponse à un problème contextuel émergeant et suffisement grave.
Et étant donné la diversité des projets, je ne vois pas pourquoi il faudrait prendre KDE comme modèle de référence. Surtout que dans mon cas le couplage interface / bibliothèque est très fort, que l'application ce contente d'être une interface plus ou moins intelligente et que la bibliothèque contient tout le moteur qui agit.
Et je ne vois pas non plus pourquoi il faudrait qu'un critère essentiel pour le monde propriétaire doit être respecté coute que coute quand il n'est pas essentiel selon un contexte donné alors que les spécificités du libre font qu'on peut justement s'en passer à un cout relativement faible.
En conclusion, je ne nie pas qu'il existe des domaines ou la compatibilité binaire puisse être interressante (toolkit graphique utilisé par une myriade d'applis, framework) mais il y en a d'autres où elle est un frein (bibliothèque de fonctionalités et non framework, voir quand c'est carrement le moteur de l'application). Tous les types étant représentés dans une distri, et certaines n'ayant rien à gagner par la préservation d'une soit disante sacro-sainte ABI qui dans leur cas ne l'est pas, on ne peut par conséquence pas atteindre une compatibilité binaire sur une distri (même en faisant semblant d'oublier que le concept de temps T de Gaël est une fumisterie).
Et oui le monde des bibliothèques est divers et ce qui est souhaitable et possible avec les unes n'est pas forcement possible avec d'autres, et encore moins souhaitable avec les dernières. Croire qu'à des contextes très différents et variés on peut à tous appliquer les mêmes critères uniformisés sans ce rendre compte qu'ils sont dans certains cas stériles revient à confondre une voiture de tourisme avec un 38 tonnes. Ce n'est pas parce que ce sont des véhicules avec des roues qui roulent sur les routes qu'ils servent à la même chose ni ne sont conçus de la même façon.
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 :)
Ça aurait un interêt je n'aurais pas à me repeter.
J'ai dis que quand on est ammené à casser la compatibilité binaire, on le fait sans scrupule (comme beaucoup de monde dans le LL au cas ou tu aurais les yeux fermés). Le besoin est loin d'être présent à chaque version, Ça arrive moins de 1x par ans. Travaillant assez étroitement avec un feedback des utilisateurs (interface graphiques et installeurs de distributions), il ne s'en plaigne pas plus que les utilisateurs de toutes les autres bibliothèques qui ont une politique proche. Ils sont donc très content merci pour eux.
Et non je n'ai pas vraiment envi de donner le nom de la bibliothèque en question vu l'insulte portée à mon égard et le fait qu'apparement un grand nombre de gens ne comprend rien au problème et s'exprime quand même sur la question.
C'est PAS parce QUE tu PARLES comme CA que CE que TU dis est PLUS lisiBLE!
Sincèrement, en tant que développeur de bibliothèque, je peux te dire une chose "mais ces entreprises ont leurs raisons qui ne sont pas les nôtres" <== tout à fait d'accord, et moi je suis developpeur de bibliothèque libre et j'ai mes raisons, qui ne sont pas celles d'un éditeur de logiciel propriétaire, qui me pousse à me contrefoutre de la compatibilité binaire si jamais elle engendre ne serait-ce que 5% de soucis en plus dans ma tête. Quand c'est trivial je vais pas m'amuser à faire exprès de tout casser. Mais quand on a besoin de changer, on change, point ! Hors de question de s'amuser à faire des hacks immondes pour que le paquet prévu pour X s'intall sur la distribution Y avec le noyau de celle de la Z.
Et heureusement (enfin malheureusement pour toi) c'est l'avis de bon nombres de développeur du libre, (y compris Linus tient), donc j'ai bien peur que l'appel de Gaël ne serve pas à grand chose. (la compatibilité au niveau source est une étape nécessaire mais non suffisante pour aller vers la compatibilité au niveau binaire (à un instant t, évidemment). <= c'est une blague ??? il veut que toutes les distri sortent en même temps tous les 6 mois ???)
(bon ok, en fait je comptes pas, la biblio est sous GPL, mais quand bien même elle serait sous LGPL je ne me priverais pas de faire la même chose...et d'ailleurs les devel de biblio sous LGPL font la même chose :P)
Et même en dehors des biblio l'environnement de la distri fait que la compatibilité binaire est... difficile (cf article sur Flash et soucis du devel par exemple). Et oui il n'y a pas que les bibliothèques et la hiérarchie dans la vie.
Au final la raison est simple et je m'étonne que Gaël n'ait pas réussit à l'identifier (sinon je ne pense pas qu'il se serait fait autant d'illusions sur la compatibilité binaire) : la diversité des distri n'a rien de comparable avec l'uniformité des OS de l'éditeur majoritaire.
(diversité des différents acteurs du developpement, des choix technologiques des distri, des modes de devel des uns et des autres, etc...). Vouloir faire concorder tout ça sur le thème au combien vaste et flou de la "compatibilité binaire" relève de l'illusion (à moins de définir et d'opérer une réduction drastique de l'étendue du champ de manoeuvres)
Parmis les établissement privés sous contrat d'association avec l'état on a aussi les ikastolak au pays basque ou le français est enseigné en basque, les écoles diwan en Bretagne, et leurs éqivalent corse, occitants (calendreta), ...
C'est un signe d'intelligence ;)
Quand FF fait rien il alloue de la mémoire pour mieux réflechir, et quand tu réduis sa fenêtre il a plus rien d'autre à faire qu'une sieste ce qui réduit ses capacités au strict minimum :P
C'est surtout que vu qu'ils utilisent un truc en XUL qui necessite un pentium 12 à 42 GHz pour s'afficher pas trop lentement (au lieu de prendre bêtement un toolkit portable), ils doivent avoir très peur de rajouter trop d'options dans les boites de dialogue pour pas que tout explose (le CPU en premier) :)
Nan mais il est question de GNU/ nul part sauf sur LFR. En générale dans de l'embarqué et à plus forte raison dans un téléphone portable, on utilise un noyau Linux avec des applis dédiées par dessus, et eventuellement des trucs comme BusyBox qui n'ont rien de GNU si on veut avoir quelques services Unix.
Je verrais mal un téléphone embarqué ne serait-ce que la glibc et un bash (et emacs et gcc aussi tant qu'on y est ? ;), mais peut-être que je me trompe. Bon la glibc à la limite mais d'habitude c'est vraiment pas ce qu'on met sur un truc avec une capacité limité, on préfère une libc plus légère.
Il veulent vraiment installer des systèmes GNU/Linux ?
J'ai rien vu de tel dans l'article. Un système embarqué basé sur Linux et des trucs comme ucLibc et BusyBox, pourquoi pas. Mais du GNU/Linux sur mobile j'ai du mal à voir l'interet (à part pour les geek :).
Mwai, il parait que les cables sous-marins en fibre optique peuvent être "écoutés" par les militaires via des techniques "d'épluchages" des gaines.
(fiabilité de la source inconnue, donc j'y mettrais pas ma main à couper... :p )
La clause 3B de Ms-PL me semble en faire une licence non libre (à vérifier) : (B) If you begin patent litigation against Microsoft over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically.
La Ms-CL contient la même clause en 3D, j'émet donc les mêmes doutes à son égard.
C'est bien ce que je dis... En C ça ne sert à rien vu que les compilateurs suppriment tous seuls comme des grands les stockages inutiles de valeurs antérieur.
Reste que vu que ça ne coute rien de le faire, et que ca habitue au BIEN dans le cas où on coderait aussi en C++ avec des opérateurs surchargés, je n'aurais rien à redire à quelqu'un qui fait systématiquement ça en C (pas plus qu'à quelqu'un qui ne le fait pas). Par contre le premier qui s'amuse à modifier un programme pour remplacer tous les postfixes sur des types primitif par un préfixe, je lui demanderais probablement s'il n'a que ça à foutre.
Mwai, enfin bon la partie Unix de MacOsX est libre, et la partie non libre ne risque pas de beaucoup interresser ceux qui tapaient dans du Solaris ou de l'Aix auparavant.
Merci de ne pas donner les noms des magnifiques créateurs de ces splendides systèmes d'envoi massif informations rayonnantes même si vous les connaissez, sinon ils vont se retrouver avec une brique plantée dans la tête comme un certain russe :P
Ce n'est pas parce qu'on réécrit tout le code qu'on a le droit de tout copier, non?
Peut-on copier le comportement d'une interface ? Assurement, sinon la vie quotidienne serait un véritable cauchemard. Peut-on copier les fonctionnalités d'une API ? Bien sûr ! GNU/Linux reproduit très bien les API Unix. À une époque il existait de nombreux clones de MS-DOS. On ne peut en fait pas vraiment parler de copie, vu que comme tu le dit très bien tout est réécrit. Le fait que cette réécriture permet d'obtenir une compatibilité avec un système est une bonne chose au sens ou la compatibilité d'un point de vue envore plus général est une bonne chose. Certains effets sont les mêmes, c'est normal. Tout comme (je sens que je vais faire une analogie foireuse car du domaine automobile, donc ça va forcement partir en vrille :) les effets de différents directions assistées sont grosso modo les mêmes, même si les dispositifs techniques qui les produits diffèrent.
Et c'est là ou les brevets sont dangeureux (entre autre). Alors que dans le monde matériel ils se contentent de protéger une technique particulière, dans le monde logiciels toute technique menant à un même effet serait interdite. Ça plus le fait que toute innovation serait de-facto impossible.
Je n'ai pas lu le fameux débat, mais vaut mieux ++i que i++ (en C et C++), c'est expliqué dans toutes les références dignes de ce nom, et c'est facilement compréhensible.
En C++ très certainement quand on travaille sur des opérateurs surchargés sur des types non atomiques. En C, étant donné que l'on est forcement sur un type primitif, je ne vois pas l'interet (notamment une instruction i++; sera équivalente à une instruction ++i;, et expr(i++); => expr(i); i++; tandis que expr(++i); => i++; expr(i); ce qui revient au même en terme de vitesse).
[^] # Re: C'est d'un goût les enfants
Posté par Guillaume Knispel . En réponse au journal Minix 3 vient de sortir.. Évalué à 5.
S'il faillait ne pas parler de tous les projets des gens qui ont eu une flamewar avec Linus un jour ou l'autre.... :) En plus ils ne sont même pas particulièrement ennemis.
[^] # Re: Mauvaise communication
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 8.
Les libertés de faire quoi ? De le garder pour soit et de travailler soit-même dessus, parce qu'on à juste pas envi de le distribuer ?
J'en ai marre (+ pas le temps) d'essayer de raisonner dans le vide et de me heurter à des personnes qui pensent tout savoir (<ironie>alors qu'il est bien évident que c'est faux puisque c'est forcement moi qui sait tout ;))</ironie> <= j'espère qu'avec les balises et le smiley tout le monde comprendra) alors je vais faire de gros copiés-collés de la FSF (ce à quoi ce qui veulent à tout prix se raccrocher au seul défaut identifiable d'Ubuntu en l'érigeant en une grave atteinte philosopique du LL s'empresseront de me rétorque que la FSF n'est pas la seule autorité, argument que je m'empresserais d'ignorer)
http://www.gnu.org/philosophy/categories.fr.html#TOCPrivateS(...)
Logiciel privé
Les logiciels privés sont développés pour un utilisateur (typiquement pour une organisation ou une société). Cet utilisateur le garde et ne publie ni les fichiers sources ni les fichiers binaires.
Un programme privé est dans un certain sens un logiciel libre si son seul utilisateur a tous les droits dessus. Cependant, en y réfléchissant un peu, cela n'a pas vraiment de sens de se poser la question de savoir si un tel programme est un logiciel libre ou non.
En général, nous ne pensons pas qu'il soit mauvais de développer un programme et de ne pas le publier. Il y a des fois où un programme est si utile que le garder pour soi est égoïste. Toutefois, la plupart des programmes ne sont pas si merveilleux que ça, et les garder pour soi n'est pas particulièrement dommageable. Donc, le développement de logiciel pour un usage privé, qui représente une grande part de l'emploi dans la programmation, ne viole pas les principes du mouvement du logiciel libre.
Pratiquement tous les emplois de programmeurs se situent dans le développement de logiciels privés; par conséquent la plupart des emplois de programmeurs sont, ou pourraient être faits d'une manière compatible avec le mouvement du logiciel libre.
Donc voilà le truc d'Ubuntu est clairement un logiciel privé, et on peut estimer que c'est dommage qu'il ne soit pas distribué et que la non distribution fait du tord à l'image d'Ubuntu, mais ça n'en fait pas un logiciel propriétaire pour autant, et on ne peut pas accuser Ubuntu d'être un éditeur de logiciel propriétaire. Pas plus que le fait d'être un logiciel commercial ne rend un logiciel libre ou propriétaire http://www.gnu.org/philosophy/categories.fr.html#TOCcommerci(...)
Même dans la GPL il n'y a pas d'obligation de distribuer, et on peut de plus très bien mélanger en toute tranquilité chez soit un logiciel sous GPL et un autre avec une licence parfaitement "incompatible" (mais qui elle aussi n'interdit pas le mélange en question en ne régisseant que la distribution et en laissant toute libertée d'effectuer des modifications) tant qu'on ne redistribue pas le tout. On peut même déployer le tout dans l'intégralité d'une entreprise si le developpement à été fait à l'intérieur de cette entreprise, quand bien même il s'agirait d'une multinationnale de 1 millions d'employés. Je ne suis pas pas sûr qu'une obligation de diffusion permette à un logiciel d'être libre.
[^] # Re: Mauvaise communication
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 3.
J'ai du mal à comprendre pourquoi autant de monde croit que c'est du proprio, alors que sous toutes les définitions que vous prenez ça n'en est évidemment pas... Et ce n'est pas la phrase "les source ne sont pas disponibles" qui devrait faire penser le contraire, même si apparement elle le fait chez les personnes qui connaissent peut les bases légales et idéologiques du LL.
Peut-être qu'en formalisant ça passera mieux (~ == négation) ?
~((LL=>(binaire=>source))=>(~source=>~LL))
[^] # Re: Compatibilite binaire
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 7.
Et le faire sans scrupule c'est carrément idiot (ou alors c'est un geste militant ?).
Ça n'a rien d'idiot ni de militant. C'est répondre à un besoin de manière efficace en gardant un code sain et non rempli de wrappers et autres choses dédiées uniquement à la compatibilité, chose que le nombre subliminal de developpeur empeche de toute façon de faire. Ça ne gène surtout pas les développeurs utilisateurs (qu'est-ce qu'il en aurait à foutre de la compatibilité binaire ? ils passent de toute manière leur journée à faire tourner GCC et se basent de toute manière toujours sur les dernières versions et ils ont raison), en rien les utilisateurs finaux (qui utilisent soit une version packagée sur leur distri ou sur un liveCD (ou d7) ou alors un binaire statique dans le "pire" des cas).
Encore une fois on ne change pas pour le plaisir, et pour rassurer ceux qui ont la critique stérile facile (manque de compétence, idiotie ???(en même temps jusqu'à présent j'ai ni concu l'archi ni pris de décision de casser la compatibilité binaire, donc finalement je suis pas si visé que ça)) l'archi est suffisement bien faites pour qu'en réalité l'ABI ne change qu'avec l'API, sauf réponse à un problème contextuel émergeant et suffisement grave.
Et étant donné la diversité des projets, je ne vois pas pourquoi il faudrait prendre KDE comme modèle de référence. Surtout que dans mon cas le couplage interface / bibliothèque est très fort, que l'application ce contente d'être une interface plus ou moins intelligente et que la bibliothèque contient tout le moteur qui agit.
Et je ne vois pas non plus pourquoi il faudrait qu'un critère essentiel pour le monde propriétaire doit être respecté coute que coute quand il n'est pas essentiel selon un contexte donné alors que les spécificités du libre font qu'on peut justement s'en passer à un cout relativement faible.
En conclusion, je ne nie pas qu'il existe des domaines ou la compatibilité binaire puisse être interressante (toolkit graphique utilisé par une myriade d'applis, framework) mais il y en a d'autres où elle est un frein (bibliothèque de fonctionalités et non framework, voir quand c'est carrement le moteur de l'application). Tous les types étant représentés dans une distri, et certaines n'ayant rien à gagner par la préservation d'une soit disante sacro-sainte ABI qui dans leur cas ne l'est pas, on ne peut par conséquence pas atteindre une compatibilité binaire sur une distri (même en faisant semblant d'oublier que le concept de temps T de Gaël est une fumisterie).
Et oui le monde des bibliothèques est divers et ce qui est souhaitable et possible avec les unes n'est pas forcement possible avec d'autres, et encore moins souhaitable avec les dernières. Croire qu'à des contextes très différents et variés on peut à tous appliquer les mêmes critères uniformisés sans ce rendre compte qu'ils sont dans certains cas stériles revient à confondre une voiture de tourisme avec un 38 tonnes. Ce n'est pas parce que ce sont des véhicules avec des roues qui roulent sur les routes qu'ils servent à la même chose ni ne sont conçus de la même façon.
[^] # Re: Libre regard du code source, POINT.
Posté par Guillaume Knispel . En réponse au journal Licence Microsoft MSR-SSLA. É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: Compatibilite binaire
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 6.
Ça aurait un interêt je n'aurais pas à me repeter.
J'ai dis que quand on est ammené à casser la compatibilité binaire, on le fait sans scrupule (comme beaucoup de monde dans le LL au cas ou tu aurais les yeux fermés). Le besoin est loin d'être présent à chaque version, Ça arrive moins de 1x par ans. Travaillant assez étroitement avec un feedback des utilisateurs (interface graphiques et installeurs de distributions), il ne s'en plaigne pas plus que les utilisateurs de toutes les autres bibliothèques qui ont une politique proche. Ils sont donc très content merci pour eux.
Et non je n'ai pas vraiment envi de donner le nom de la bibliothèque en question vu l'insulte portée à mon égard et le fait qu'apparement un grand nombre de gens ne comprend rien au problème et s'exprime quand même sur la question.
[^] # Re: Compatibilite binaire
Posté par Guillaume Knispel . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 4.
Sincèrement, en tant que développeur de bibliothèque, je peux te dire une chose "mais ces entreprises ont leurs raisons qui ne sont pas les nôtres" <== tout à fait d'accord, et moi je suis developpeur de bibliothèque libre et j'ai mes raisons, qui ne sont pas celles d'un éditeur de logiciel propriétaire, qui me pousse à me contrefoutre de la compatibilité binaire si jamais elle engendre ne serait-ce que 5% de soucis en plus dans ma tête. Quand c'est trivial je vais pas m'amuser à faire exprès de tout casser. Mais quand on a besoin de changer, on change, point ! Hors de question de s'amuser à faire des hacks immondes pour que le paquet prévu pour X s'intall sur la distribution Y avec le noyau de celle de la Z.
Et heureusement (enfin malheureusement pour toi) c'est l'avis de bon nombres de développeur du libre, (y compris Linus tient), donc j'ai bien peur que l'appel de Gaël ne serve pas à grand chose. (la compatibilité au niveau source est une étape nécessaire mais non suffisante pour aller vers la compatibilité au niveau binaire (à un instant t, évidemment). <= c'est une blague ??? il veut que toutes les distri sortent en même temps tous les 6 mois ???)
(bon ok, en fait je comptes pas, la biblio est sous GPL, mais quand bien même elle serait sous LGPL je ne me priverais pas de faire la même chose...et d'ailleurs les devel de biblio sous LGPL font la même chose :P)
Et même en dehors des biblio l'environnement de la distri fait que la compatibilité binaire est... difficile (cf article sur Flash et soucis du devel par exemple). Et oui il n'y a pas que les bibliothèques et la hiérarchie dans la vie.
Au final la raison est simple et je m'étonne que Gaël n'ait pas réussit à l'identifier (sinon je ne pense pas qu'il se serait fait autant d'illusions sur la compatibilité binaire) : la diversité des distri n'a rien de comparable avec l'uniformité des OS de l'éditeur majoritaire.
(diversité des différents acteurs du developpement, des choix technologiques des distri, des modes de devel des uns et des autres, etc...). Vouloir faire concorder tout ça sur le thème au combien vaste et flou de la "compatibilité binaire" relève de l'illusion (à moins de définir et d'opérer une réduction drastique de l'étendue du champ de manoeuvres)
[^] # Re: Libre et privé ...
Posté par Guillaume Knispel . En réponse à la dépêche Faire entrer les logiciels libres à l'école. Évalué à 1.
MOUAHHAHAH... oups, désolé
(nan sincèrement j'aurais pas du ;)
[^] # Re: Décidément, que de surprises !
Posté par Guillaume Knispel . En réponse au journal Quand un gouvernement s'arrange pour mettre des mouchards dans les objets courants. Évalué à 2.
Et le pire c'est que presque tout le monde s'en fout, même quand on leur met le nez dedans.
[^] # Re: A propos de la mémoire
Posté par Guillaume Knispel . En réponse au journal Firefox cache mal son jeu. Évalué à 2.
Quand FF fait rien il alloue de la mémoire pour mieux réflechir, et quand tu réduis sa fenêtre il a plus rien d'autre à faire qu'une sieste ce qui réduit ses capacités au strict minimum :P
[^] # Re: Une lueur d'espoir ...
Posté par Guillaume Knispel . En réponse au journal Firefox cache mal son jeu. Évalué à 5.
[^] # Re: Cache-cache
Posté par Guillaume Knispel . En réponse au journal Firefox cache mal son jeu. Évalué à 10.
[^] # Re: GNU/Linux ?
Posté par Guillaume Knispel . En réponse à la dépêche L'OSDL créé le Mobile Linux Initiative. Évalué à 6.
Je verrais mal un téléphone embarqué ne serait-ce que la glibc et un bash (et emacs et gcc aussi tant qu'on y est ? ;), mais peut-être que je me trompe. Bon la glibc à la limite mais d'habitude c'est vraiment pas ce qu'on met sur un truc avec une capacité limité, on préfère une libc plus légère.
# GNU/Linux ?
Posté par Guillaume Knispel . En réponse à la dépêche L'OSDL créé le Mobile Linux Initiative. Évalué à 2.
J'ai rien vu de tel dans l'article. Un système embarqué basé sur Linux et des trucs comme ucLibc et BusyBox, pourquoi pas. Mais du GNU/Linux sur mobile j'ai du mal à voir l'interet (à part pour les geek :).
[^] # Re: Ben ...
Posté par Guillaume Knispel . En réponse au journal Câbles sous-marins et répéteurs. Évalué à 2.
(fiabilité de la source inconnue, donc j'y mettrais pas ma main à couper... :p )
# hm pas sûr qu'elles sont libres.
Posté par Guillaume Knispel . En réponse au journal Des licences libres chez Microsoft ?!. Évalué à 3.
(B) If you begin patent litigation against Microsoft over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically.
La Ms-CL contient la même clause en 3D, j'émet donc les mêmes doutes à son égard.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . En réponse à la dépêche Rendre GNOME rapide. Évalué à 2.
Reste que vu que ça ne coute rien de le faire, et que ca habitue au BIEN dans le cas où on coderait aussi en C++ avec des opérateurs surchargés, je n'aurais rien à redire à quelqu'un qui fait systématiquement ça en C (pas plus qu'à quelqu'un qui ne le fait pas). Par contre le premier qui s'amuse à modifier un programme pour remplacer tous les postfixes sur des types primitif par un préfixe, je lui demanderais probablement s'il n'a que ça à foutre.
[^] # Re: yen au moins un qui vit encore
Posté par Guillaume Knispel . En réponse au journal La fin des Unix propriétaires ?. Évalué à 9.
# Merci de ne pas...
Posté par Guillaume Knispel . En réponse au journal Luce et Henri font du spam. Évalué à 5.
[^] # Re: mouchards partout, corruption aussi, F2F P2P
Posté par Guillaume Knispel . En réponse au journal Quand un gouvernement s'arrange pour mettre des mouchards dans les objets courants. Évalué à 2.
[^] # Re: composition
Posté par Guillaume Knispel . En réponse au journal ReactOS avance. Évalué à 4.
Peut-on copier le comportement d'une interface ? Assurement, sinon la vie quotidienne serait un véritable cauchemard. Peut-on copier les fonctionnalités d'une API ? Bien sûr ! GNU/Linux reproduit très bien les API Unix. À une époque il existait de nombreux clones de MS-DOS. On ne peut en fait pas vraiment parler de copie, vu que comme tu le dit très bien tout est réécrit. Le fait que cette réécriture permet d'obtenir une compatibilité avec un système est une bonne chose au sens ou la compatibilité d'un point de vue envore plus général est une bonne chose. Certains effets sont les mêmes, c'est normal. Tout comme (je sens que je vais faire une analogie foireuse car du domaine automobile, donc ça va forcement partir en vrille :) les effets de différents directions assistées sont grosso modo les mêmes, même si les dispositifs techniques qui les produits diffèrent.
Et c'est là ou les brevets sont dangeureux (entre autre). Alors que dans le monde matériel ils se contentent de protéger une technique particulière, dans le monde logiciels toute technique menant à un même effet serait interdite. Ça plus le fait que toute innovation serait de-facto impossible.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . En réponse à la dépêche Rendre GNOME rapide. Évalué à 5.
[^] # Re: Effectivement
Posté par Guillaume Knispel . En réponse à la dépêche Rendre GNOME rapide. Évalué à 4.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . En réponse à la dépêche Rendre GNOME rapide. Évalué à 7.
En C++ très certainement quand on travaille sur des opérateurs surchargés sur des types non atomiques. En C, étant donné que l'on est forcement sur un type primitif, je ne vois pas l'interet (notamment une instruction i++; sera équivalente à une instruction ++i;, et expr(i++); => expr(i); i++; tandis que expr(++i); => i++; expr(i); ce qui revient au même en terme de vitesse).
[^] # Re: A la limite du sujet
Posté par Guillaume Knispel . En réponse à la dépêche DMCA français : lettre à Dominique de Villepin. Évalué à 2.
Surrement reversée aux multinationnales du divertissement.