benoar a écrit 4244 commentaires

Excuse-moi pour le message précédent, je vais la refaire plus calme :

Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".

La volonté des développeurs du noyau n'est pas de "fermer" son développement en préférant intégrer les drivers dans la branche principale, mais de prévenir les développeurs externes qu'ils vont devoir s'adapter régulièrement à des petits changements s'ils décident de rester en dehors. Comme ça, ils sont prévenus et n'ont pas à gueuler après, que c'est comme ça que ça se passe quand on fait du dev sur le kernel. Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.

Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.

Là, tu demandes à redéfinir les bases de notre discussion : jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur. Mais donc ce que tu proposes aujourd'hui c'est de standardiser l'interface driver ? Ca demande un autre débat ...

Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.

Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.

T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?

D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ? Le changement sera d'autant plus grand ! Des changements petit à petit ça permet justement de pas trop perdre de drivers d'un coup, de faire la transition "doucement" (même si ça casse à chaque fois, les modifications sont mineures). Arriver à une bonne API du premier coup est quasi impossible, c'est pour ça que le code n'est jamais vraiment réécrit "from scratch" quand on propose une nouvelle API. Et ce n'est pas parce que ce n'est pas refait complètement que c'est bancal ! Franchement, regarde les sources du noyau, ya des fichiers qui ont encore l'entête de linux avant la 1.0, et pourtant ils sont aujourd'hui, après modifications successives, très bien intégrés à l'ensemble.

Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).

Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ? (c'est pas pour te faire chier à montrer que j'ai raison ou que t'en trouves pas, c'est vraiment pour étudier le problème plus concrètement) Des changements d'ABI incessants, peut-être, et c'est normal, pour l'API par contre ... à moins que tu ne parles d'une section encore expérimentale ou en cours de développement ?

Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)

Pour ton problème spécifique, ça me paraît dommage en effet, c'est peut-être le manque de détermination du dev qui a fait que peu de personnes se sont intéressées à l'intégration... alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes (selon moi, je ne connais pas vraiment grand monde qui a une AIW), il faut arriver à convaincre les devs upstream que son problème est important. C'est toujours pareil, on est pas dans une entreprise, on est dans un projet communautaire ... Bon, ça doit pas devenir une excuse, effectivement pour ce cas là il y a effectivement un problème, mais ce n'est pas un problème d'API selon moi (sinon je veux bien quelques liens pour mieux comprendre).
Pour le coup des devs qui changent l'API rien que pour faire chier les devs proprio, je te laisse dans ta parano, ce n'est pas du tout ce que j'ai dit.

Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".

Je comprend ce que tu veux dire par là, mais je ne serais pas aussi extrême : oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".

Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.

Alors moi aussi je vais dire que tu fais exprès de ne pas comprendre : POSIX désigne une interface utilisateur, ce qui n'a rien à voir avec une interface driver. On aura toujours une API permettant d'ouvrir un fichier avec une fonction, de lire tant d'octets avec une autre, etc ... Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter. Et même les anciennes suivent le pas.

Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.

Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes (je n'ai pas dit que tu n'avais pas le droit de donner ton avis par contre, soyons clairs). Cela devrait être réglé par les devs. Je trouve ça dommage par contre si certains utilisent leur communauté d'utilisateur comme moyen de chantage sur d'autres devs.

C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.

J'ai cité l'intégralité de ton commentaire, en analysant phrase par phrase, et en m'efforçant de comprendre quand ce n'était pas des critiques lancées gratuitement en l'air.

Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.

Oui, dans l'idéal, ce serait comme ça qu'il faudrait faire. Mais trouve moi quelqu'un qui arrive du premier coup à rassembler toutes ces qualités dans son code. Il n'existe aujourd'hui aucun OS capable de cela sans un minimum de changement de code et de cassage d'API.

Je pense que tout le problème, c'est de décider entre avoir un truc très stable mais sur lequel il faudra bidouiller au cas où on a pas visé juste du premier coup, ou alors faire un truc qui évolue tout le temps, mais qui casse régulièrements les APIs. La solution choisie pour linux est la 2e, et la philosophie du développement kernel, ça a toujours été d'effectuer les changements petit à petit, sans trop gros accoups. Au final, cela permet d'évoluer plus vite, et la modularisation arrive petit à petit; un jour, on verra peut-être une interface stable aux drivers, quand le kernel aura bien été séparé et "standardisé". Par exemple, la possibilité d'utiliser une machine sans MMU (changement assez profond, quand même), n'a été intégrée qu'au 2.6, alors qu'il existait des patches depuis quelques temps pour le 2.4, mais il a fallu la volonté des devs et leur persévérance pour changer petit à petit le code du noyau, jusqu'à être intégrés upstream.

Ha ça y est, t'as trouvé un sujet sur lequel te défouler :

Ah elle est jolie la philosophie de l'interopérabilité ! Ah elle est jolie la critique de MS lorsqu'ils cassent la compatibilité avec un standard !

Ce dont on parle n'a rien à voir avec un standard, c'est la cuisine interne du noyau. Critique gratuite à 2 fr qui n'a rien à voir avec le sujet.

Faudrait standardiser les interfaces du kernel pour rigoler tiens.

Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.

Heuresement que à la couche supérieur y'a eu POSIX, sinon j'imagine même pas dans quel bordel on serait. C'est pas au même étage, mais les problématiques sont les mêmes.

Bah justement, comme c'est à un niveau plus élevé, c'est d'une certaine manière plus facile à respecter, puisque le "sens" de l'API est plus élevé, et qu'on est pas dans la cuisine bas-niveau.

Linus & Co veulent tout maîtriser et veulent forcer tout le monde à rentrer dans leur tronc commun (sous peine d'être un driver de seconde classe jamais synchronisé tellement ca change souvent).

Ha oui, bien sûr, la conspiration contre les petits développeurs et les constructeurs ...

C'est quand même pas compliqué de conserver un API tel quel, et d'en faire un nouveau en repartant de 0 à côté, les 2 pouvant marcher côte côte, l'un pour les anciens drivers, l'autre pour les nouveaux.

Ho non, ça demande juste de recoder complètement une partie du noyau tout en en maintenant une autre, soit à peu près le double d'effort.
Pour un exemple de compications dues à ça, regarde le temps qu'il faut pour intégrer la pile ieee80211 de Devicescape : ça fait un bout de temps qu'on en parle et qu'elle est toujours pas upstream, et pendant ce temps il faut continuer à faire évoluer en parallèle celle d'Intel.

Non, faut dire ce qui est, garder la compatibilité, ca les fait chier.

Oui, ça les fait chier de garder des anciennes API pourries pour les beaux yeux de contructeurs qui font du proprio et veulent des API bien stables.

Ca serait pourtant plus simple que de perdre son temps à continuellement modifier une énorme base de driver.

Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !

Une API de qualité est avant tout une API conçue pour être pérenne dans le temps, bref, conçu pour le présent et l'avenir. Le fait d'avoir les sources et la main mise sur l'ensemble des drivers ne doit pas être une excuse pour occulter ce manque de qualité.

Oui c'est mieux d'avoir une API stable, mais ce n'est pas toujours possible. Le kernel avance très vite, et c'est cela qui a beaucoup bousculé le monde proprio : les changements d'API arrivent donc plus souvent, et d'un coté c'est clair que la disposition des sources incite d'autant plus à ne pas se restreindre à une vieille API car le mode de développement du libre permet de facilement faire évoluer tous les drivers ensemble.

Enfin ca me fait marrer cette comparaison avec le fork... En tout cas ca montre bien le modèle de développement du kernel : complètement fermé vers l'extérieur. Ils veulent tout maîtriser, ils en ont rien à péter de s'interfacer avec des briques extérieures.

N'importe quoi, les changements assez profonds sont prévus à l'avance, bien documentés. Par contre, ils n'en ont effectivement rien à péter que des gens leurs imposent leur méthodes de travail : le libre avance comme ça et c'est tout. C'est le même genre de tendance qu'on a vu arriver avec le changement d'ABI d'Xorg 7.1 : certains utilisateurs ce sont mis à critiquer les packageurs de mettre Xorg 7.1 dans leur distro car NVidia et ATI n'avaient pas encore sorti de drivers compatibles avec la nouvelle API ! Ce n'est pas au monde du proprio de dicter la manière dont doivent évoluer les déveoppeurs. Dans le libre, ceux qui peuvent avoir un poid sur les discussions, ce sont ceux qui jouent le jeu du libre. Et donc surement pas NVidia et ATI.

Logiciel libre avec une interface fermée, ca me paraît à l'opposé philosophiquement.

Encore du n'importe quoi, les changements sont généralement documentés.

C'est quand même rigolo, à l'époque où les Unix étaient tous proprio, eux avait pensé interopérabilité avec POSIX.

Arf, comme tu dis au début de ton commentaire, Linux est toujours compatible POSIX malgré les changements dont on parle ici, heureusement. Encore du n'importe quoi.

Exemple de problème de pérénité dans le temps : en tant qu'utilisateur j'aimerai qu'on me laisse ma liberté de conserver des anciens pilotes tout en en profitant des mises-à-jour de pilotes plus récent. Non, le noyau me laisse pas le choix, si t'upgrade, faut tout upgrader. Et non, les maj n'apporte pas que des améliorations, y'a aussi parfois des régressions.

Alors là, tu pousses un peu le bouchon : tu utilises le mot liberté pour obtenir arbitrairement des choses des gens, ce qui montre bien ton intolérance. Moi aussi j'aimerais bien avoir la liberté de te faire fermer ta gueule des fois, mais bon ...

PS: Désolé pour la vulgarité, mais te voir dire tant de bêtises et te faire plusser ça m'énerve

On peut aussi choisir de publier son "invention" et ainsi avoir une preuve d'antériorité en cas de dépot de la part d'un concurrent...

Mais oui c'est n'importe quoi les brevets.

Je voudrais te poser une question : si tu trouves que les brevets c'est n'importe quoi, pourquoi est-ce que tu en poses de temps en temps ?

Je sais que ta réponse va être du genre "dans le cadre de mon boulot, je n'ai pas le choix", mais je trouve que c'est un peu la solution de facilité, d'ailleurs même celle que tout le monde choisi aujourd'hui (regarder le Canard de la semaine dernière à propos de ça, sur le film "Ma mondialisation" de ... je ne sais plus qui, qui parle de chefs d'entreprises "obligés" de délocaliser). Si plus personne aujourd'hui n'a le choix, ou va-t-on ?

Bon, j'arrête ici car moi non plus je ne serais pas crédible sur d'autres sujets, mais je te posais la question pour savoir si tu y réfléchissais beaucoup et si tu essayais de combattre un peu aussi à ta manière.

Dommage, avec le ton que tu emploies tu ne pourra surement pas inaugurer ton 2e commentaire avant quelques temps...

Sinon, si tu pouvais argumenter et éviter d'insulter les gens, je suis sûr que tu pourrais trouver des gens qui sont plus ou moins d'accord avec toi, car sous certains aspects je suis un peu d'accord avec toi.

Enfin, tu pourrais préciser ce que tu as fais ? Je ne veux pas te pousser à "te la péter" en listant tes projets, mais es-tu LE benh de debian-ppc ?

J'ai également du mal à croire que Novell est innocent, et qu'ils se sont faits bêtement avoir. Quand Ron dit :

When we entered the patent cooperation agreement with Microsoft, Novell did not agree or admit that Linux or any other Novell offering violates Microsoft patents.

ça me fait doucement marrer. Dans "Patent agreement", il y a "patent", et donc, si on en signe un, c'est bien qu'on pense avoir "besoin" de cet accord pour se protéger, non ? Ils sont quand même pas si con pour pas avoir compris ça chez Novell, merde !

En plus, si on regarde bien dans la FAQ de Novell ( http://www.novell.com/linux/microsoft/faq_opensource.html ), en ce qui conerne l'accord sur les brevets, ils est expliqué que :
- Cet accord de "non attaque" de la part des deux signataires n'est pas un accord de licence d'utilisation de brevet, et que ça ne défend donc en rien les possibles violations de brevets, c.f. la Q1 (qui, du reste, n'est vraiment pas claire, je trouve) :

Our agreement with Microsoft is focused on our customers, and does not include a patent license or covenant not to sue from Microsoft to Novell.

- Que de toutes façons, Mono n'enfreint de de brevets de Microsoft, c.f. la Q8 :

We maintain that Mono does not infringe any Microsoft patents.

Donc au final, on a un accord de "non-attaque" de la part de Microsoft qui ne protège pas de ses attaques, sur des violations de brevets qui n'exsitent pas. Si c'est pas un accord utile, ça ! Et en plus, ils le payent 40 M$ par an...

Il y a une petite nuance, il me semble :
On peut effectivement incorporer du code BSD dans un projet GPL, mais il ne "devient" pas GPL, car on ne peut pas changer la licence du code dont on a pas le copyright. C'est juste que les conditions de redistributions suivent la licence la plus "stricte", celle de la GPL. Mais quelqu'un peut très bien récupérer la partie BSD du projet GPL et en faire un logiciel proprio (OK, il n'y a pas beaucoup d'intérêt par rapport à la version originale BSD d'où est tiré le code).

Mais c'est justement ca que j'ai l'impression que personne ne comprend : Novell n'acquiert pas de licence d'utilisation de brevet dans cet accord ! Novell n'a pas l'autorisation d'utiliser les brevets de MS sans passer d'accord explicite traditionnel. Conclusion ils continuent leur stratégie précédente vis-à-vis des problèmes de violation de brevet : "prior-art, contournement ou suppression"

Maintenant qu'on s'est mis d'accord sur ce point, je me rend compte d'un truc : effectivement, Novell n'a pas de licence d'utilisation mais seulement un accord de "non aggression", mais c'est à mon avis très bien étudié, car un accord d'utilisation violerait la section 7 de la GPL, et ça ils le savent très bien. Donc le seul moyen pour eux de se protéger légalement de Microsoft, c'était de passer cet accord. À mon avis, ils auraient bien voulu acheter des licences à Microsoft, mais ils ne pouvaient légalement pas, selon les conditions de la GPL. Car le coup du "Novell protègera tous les devs indépendants s'ils se font attaquer sur Mono" j'y crois pas du tout. Ils auraient pu avoir un accord d'utilisation juste pour leurs clients et pas les autres, ils l'auraient fait. D'ailleurs, en pratique, c'est ce que va devenir cet accord.

Donc pour moi, cet accord c'est comme un accord d'utilisation des brevets de Microsoft, même si techniquement ce n'en est pas un, car ça serait illégal.

plutôt que de chercher à passer un accord d'utilisation d'un brevet pour rendre le logiciel légal, on les ignore.

Oui, mais le problème, comme tu le dis bien plus bas, c'est que les brevets logiciels c'est de la merde, et qu'aucun développeur de logiciel libre ne voudra passer d'accord avec une boite sur une chose qu'il trouve complètement abhérante. En plus, pour pouvoir passer une accord, il faut apporter quelque chose en compensation de l'utilisation du brevet, genre une licence d'utilisation pour un brevet que le développeur détient (quel développeur de LL aimerait poser un brevet sur une techno ? la plupart ne préfèrent pas et comptent sur la diffusion publique pour avoir une preuve d'antériorité au cas où une boite veuille en déposer un) ou alors une compensation financière, et ça, aucun développeur de LL ne voudra (puisqu'en plus ça viole la section 7). Donc pour moi, et surement pour beaucoup d'autres, logiciels libres et brevets sont incompatibles.

Bien sûr, une grosse boite qui aura un portefeuille de brevets pour négocier y arrivera (et oui, je sais que même RedHat a déposé des brevets), mais à terme, cela tuera le développement communautaire. A moins que chaque développeur veuille se rattacher à une boite qui puisse le défendre, mais moi je revendique le droit à développer seul les LL que je veux, sans avoir besoin de la protection d'une boite (qui devra forcément avoir un intérêt à te protéger, donc qui aura le pouvoir de choisir les développeurs qu'elle protègera ou non : encore une source d'insécurité pour les développeurs de LL)

Ce que je ne comprend pas, c'est que tu parles de te mettre en accord avec la loi, sachant que tu trouves cette loi débile. Et pour moi, essayer de se mettre en conformité avec cette loi, c'est déjà un peu lui donner du crédit.

Bon alors, je suis à peu près d'accord sur le fait qu'il y a une nuance entre le fait d'obtenir une licence d'utilisation de brevet, et un accord de non-poursuite judiciaire, mais alors je ne dirais pas que c'est "complètement différent". C'est juste une manière un peu déguisée d'avoir les droits d'une licence, mais sans toutes les garanties (puisque Microsoft peur arrêter le deal quand ils veulent, cf. la fin de la page que je t'ai indiquée; j'avoue que je ne suis pas sûr des termes, j'ai un peu de mal à capter la phrase).

Mais tout ça me fait dire que c'est pour faire planner un doute énorme sur les brevets contenus (ou non) dans les technos Novell. En plus, quand on regarde la section 7 de la GPL, on parle de licence d'utilisation ou même d'allégation de violation de brevet : ce que fait Microsoft en signant cet accord avec Novell n'est peut-être pas une déclaration que ses LL violent des brevets, mais ça en est vraiment pas loin ! Moi, je trouve que c'est une manière détournée de violer la section 7 sans vraiment la violer (puisqu'ils n'ont fait aucune déclaration de violation de brevet, ni n'ont d'accord de licence) et je trouve cela franchement dégueulasse et dangereux pour le LL.

Pour l'histoire des 180 jours, cela coucerne les produits gratuits destinés au développement et aux tests, pas les releases finales ! Ce qui change quand même pas mal de choses (et puis se dire que ta distribution est à l'abris pour 6 mois, mais qu'après, tu risque le procès, moi, ça m'incite même pas à commencer à l'utiliser).

Pour ta dernière remarques, effectivement, comme le fait remarquer Antoine, c'est facile de gober tout ce qu'ils racontent. Je ne dis pas qu'il ne faut pas du tout leur faire confiance, mais avoir un minimum d'esprit critique, et se dire que partout dans le monde il y a des choses que certains n'osent pas dire directement pour éviter de choquer les autres, comme dans cet accord. Croire qu'il n'y a absolument aucun danger et que cet accord n'implique rien de bien grave, c'est être un peu naïf.

Hors il n'y a aucun accord de licence ou de brevets quelconque.

Ho ! Alors j'ai du rêver en lisant ça :

Microsoft, on behalf of itself and its Subsidiaries (collectively ?Microsoft?), hereby covenants not to sue Novell?s Customers and Novell?s Subsidiaries? Customers for infringement under Covered Patents of Microsoft on account of a such Customers? use of specific copies of a Covered Product as distributed by Novell or its Subsidiaries (collectively ?Novell?) for which Novell has received Revenue (directly or indirectly) for such specific copies; provided the foregoing covenant is limited to use by a Customer of Novell (i) of such specific copies that are authorized by Novell in consideration for such Revenue, and (ii) within the scope authorized by Novell in consideration for such Revenue.

http://www.microsoft.com/interop/msnovellcollab/patent_agree(...)

Il est très explicitement écrit que Microsoft ne poursuivra pas les clients de Novell qui ont acheté un produit Novell (il est bien précisé en plus dans la suite du paragraphe, qu'il faut l'avoir payé ! cf. la clarification sur le "perceived Revenue"). Je ne comprend pas ton obstination à faire du FUD. Le pire, c'est que plus on te le prouve, plus tu te renferme sur tes positions, en ressortants les mêmes affirmations non argumentées. Ou alors prouve moi où j'ai tort : ça m'intéresse (sincèrement).

Je crois que le sujet de la vente liée est aussi vieux que linuxfr, alors depuis le temps je me suis un peu découragé, et je me demande s'il ne faudrait pas plutôt y aller petit à petit, et d'abord demander un affichage séparé du prix matériel / logiciel. Ainsi, cela ferait peut-être changer la mentalité des gens, qui se soucieraient un peu plus du logiciel en voyant qu'il ne coûte pas rien (comme beaucoup de gens aujourd'hui l'imaginent encore, malheureusement... demandez à n'importe qui le prix de windows, personne ne le connait puisqu'il "a été livré gratuitement avec mon PC" ...).

Il y a toujours le problème, selon pBpG, du prix que les constructeurs ne peuvent pas révéler, mais ça j'en ai un peu rien à foutre : en tant que consommateur, on a le droit d'avoir une information claire, et en plus, ils n'ont pas le droit de vendre à perte, donc pas le droit de nous dire que leur windows n'a coûté que 10¤. J'avais aussi entendu parler des bundles qui faisaient réduire le prix du PC, bref, plein d'entourloupes pour nous faire acheter un max de logiciels sans qu'on en ai réellement besoin, mais tout ça n'est vraiment pas clair et selon moi à la limite de la légalité, donc pour éclaircir tout ça : affichage des prix logiciel / matériel !

Sinon, même remarque que quelques autres à propos du terme "racketiciel" : je trouve son utilisation vraiment un peu forte, et ceci a été fait remarquer dès le début de la pétition il y a quelques temps. Malheureusement le changement n'a pas été fait au début, et il est maintenant impossible de revenir dessus après tant de signatures : c'est dommage, j'hésite encore à signer...

Le jour ou on retrouvera les sources de linuxfr... J'ai remarqué qu'elles reviennent périodiquement, puis redisparaissent. Si quelqu'un les retrouve, franchement, je veux bien m'y pencher.

Oui, sauf que on appelle blob un firmware, un driver proprio, ou un programme proprio, sans faire la distinction.
En l'occurence, dans notre cas, on ne parle pas du tout de driver binaire : quand les gens parlent des "blobs" d'Intel, ici, c'est soit le firmware (qui tourne sur la carte wifi), soit un démon proprio (qui tourne donc en espace utilisateur, pas en noyau). Ce n'est pas le cas que tu décris (c'est pour ça d'ailleurs que je trouve que blob porte à confusion : je n'ai pas l'impression qu'on parle du même blob).

Avec Intel, c'est des fois "libre", et des fois moins libre.

Les chipsets IPW2100 & IPW2200 (respectivement pour les Centrino à base de Pentium M et de Core Duo) ont un driver libre, accompagné comme la plupart des chips d'autres marques, d'un firmware proprio. (faut que tout le monde arrête d'appeler "blob" tout et n'importe quoi : à la base, c'est une notion de BDD...).

Par contre, les chips IPW3945 (pour les Core 2 Duo) ont un dirver libre ayant besoin d'un daemon proprio (sous linux) qui tourne en user space, + un firmware proprio. Et là c'est beaucoup moins top. Comme indiqué plus haut, pour OpenBSD, le driver est entièrement libre et sans démon grâce au travail de reverse engeneering de Damien Bergamini.

Ca pourrait être intégré à Linux, mais je pense qu'il y a des tensions de parts et d'autres : d'un coté c'est Intel qui maintient les drivers libres Intel (intégrés au noyau); ça leur ferait peut-être pas plaisir que quelqu'un se ramène avec une version libérée tout en demandant à ce qu'ils maintiennent les autres drivers déjà libres (bon, d'un côté, on a aucune obligation de faire plaisir à Intel, c'est clair; ni Intel n'a d'obligation de continuer à maintenir ses drivers). Mais bon d'un coté, il me semble que les devs du kernel sont en train de virer la pile ieee80211 softmac de Intel (utilisée par quelques chips softmac, dont ceux des Centrino) pour celle de DeviceScape, donc ça a l'air bien parti pour la bataille...

Ho, putain, t'es lourd des fois TImaniac, rien qu'a te lire ça m'énèrve, alors j'imagine pas le courage de ceux qui "discutent" avec toi (ce serai plus un dialogue de sourd qu'autre chose ...). Tu dis :

Bizzarement Python fait parti des logiciels libres référencés comme "protégés" par l'OIN, c'est que Novell/RedHat/Sony/IBM avait une bonne raison de croire qu'ils pouvaient éventuellement être en danger !

Et juste après, quand Antoine cite ton passage, tu réponds :

Vois pas ce qu'il y a d'incertain, de doute là dedans.

Ca me rappelle limite le sketch de Coluche avec les milieux autorisés qui s'autorisent à croire ...

Il faudrait que je trouve un algo de comparaison de fichiers binaires.

Tu seras peut-être intéressé par ça :
http://www.daemonology.net/bsdiff/

Demande son avis à Richard Stallman : http://thomas.apestaart.org/gallery/main.php?g2_itemId=14498

Pour le cas spécial, peut-être :
!(x ^ 0xff) || !((x ^ 0xff) - 1)
non ?
Sinon, pourquoi est-ce que la comparaison ne serait "pas efficace" ?

Houa, le site de Gucci est halucinant, ya même la petite roue façon flash pour le chargement... j'avais pas vu ça depuis un bout de temps (et oui, je n'ai pas le plugin flash). Franchement, je pensais pas qu'on pouvait faire aussi bien avec du javascript !

J'avais lu sur hardware.fr que la "mode" du 16/10 était en fait une "optimisation" de la production de dalles, car ainsi il y avait moins de perte en découpant les écran à ce rapport plutôt qu'à 4:3. C'est ici : http://www.hardware.fr/articles/619-1/comparatif-maj-13-lcd-(...)

Dois-je rappeler que favoriser le non-libre, c'est aussi empêcher techniquement (et pas seulement philosophiquement) ceux qui ne sont pas sur plateforme x86 d'utiliser ces technologies ? Je suis d'accord que ce n'est qu'un "effet de bord" de sa volonté de refuser tout ce qui est non-libre, mais j'ai l'impression que certaines personnes ne s'en rendent pas compte...

Bon, avant que ça parte en troll sur du vent, le lient vers le discours de Razzye Hammadi : http://www.mjsfrance.org/article.php3?id_article=679 .
Qui parle effectivement de Microsoft comme pourrait l'être n'importe quelle autre grosse multinationale, mais avec une petite référence au logiciel libre, quand même, précédé d'une blague de merde sur windows...

Les quelques CDs "copy controlled" auxquels j'ai eu à faire utilisent une méthode très simple à contourner :
La première piste audio ets marquée comme étant une data, et à la fin il y a une dernière piste data contenant le petit player pour windows (qui lit le CD avec un son dégradé ...). Donc ça suffit pour que Windows le voit comme un CD entièrement data, et que l'on soit donc obligé d'utiliser le player intégré (qui, bien sûr, n'autorise pas à extraire les piste, juste les écouter).
Sous linux, il suffit de "dire" à ton ripper que la 1ere piste est bien une audio, et de ne pas s'occuper de la dernière. Je pense qu'un patch gérant ça est intégré à la plupart des rippers. Il y a aussi l'histoire des mauvais checksums intégré au CD, mais ce "problème" n'est vu que par ton lecteur CD.
Donc en bref, tout lecteur CD un minimum récent (je dirais, 5-6 ans) ou pas trop mal fait peut lire ces cochonneries, du moment que le soft derrière sache se débrouiller avec le résultat.

Mais cela n'empêche pas de boycotter ces CDs, qui ne sont pas de vrais "Compact Disc" et qui feront toujours chier tout le monde (ma chaîne hifi ne les lit pas), et qui sont en plus moins résistants que les vrais CDs (car les checksums sont mauvais à l'origine, donc impossible de corriger une petite erreur dûe à une rayure, par exemple).

Vu les connaissances en informatique de tous les participants du gouvernement lors du vote de la loi DADVSI, si tu la ramènes en disant que t'as essayé de le lire sous linux, il vont croire que t'es un méchant pirate qui a essayé de contourner la protection ! Et hop, direct la case prison...