Posté par benoar .
En réponse au journal Erudissey.
Évalué à 2.
Bon alors j'ai diverse raison (de plus ou moins mauvaise fois) qui ne me motivent pas à le faire :
- j'ai pas les symboles de débugage, va falloir recompiler cairo (et mon petit G4 800 se traine un peu)
- cairo marche déjà pas trop mal avec GTK2, donc je suppose que le problème vient de gecko (ou Xorg), ce qui m'amène à :
- je suis un peu malade du code de gecko et de X (j'avoue n'avoir que survolé gecko, mais je suppose que c'est pareil que Xorg : j'en peu plus tellement le code est lourd et imbitable)
- ma plate-forme (ppc) et mon système sont un peu spéciaux, je bidouille plein de trucs, donc je ne me retrouve jamais dans les mêmes situations que les devs ce qui fait que souvent les problèmes viennent d'autre part sans que je puisse jamais savoir si le problème va être reproductible (par exemple les lenteurs de X sur ppc sont surement du à la non optimisation des routines pour le frame buffer : personne ne s'en rend compte sur x86 car c'est optimisé MMX et que tout est fait dans l'ALU classique sur ppc. J'ai essayé quelques optimisations, mais ça a pas mené à grand chose vu que la manière dont est architecturé Xorg fait que le code vectoriel dépend beaucoup de la vitesse du bus mémoire et qu'à ce niveau, l'Altivec est pourri. Et que mes tentatives à une époque avec E17 n'ont rien donné vu que le patch que j'ai envoyé n'a jamais atteint le CVS vu que tout le monde s'en branle du ppc)
Bon alors je pourrais laisser le boulot aux devs de cairo ... mais ça me semble un peu injuste vu que j'aurai peut-être les compétences pour le faire. Enfin bon oui, je pourrais rester au simple role de testeur...
Mais le DNS est déjà géré par un organisme mondial, l'ICANN, alors pourquoi pas le SMTP ?
C'est vrai qu'il y a quelques problèmes de centralisation de la responsabilité de qui a le droit d'avoir un nom de domaine ou pas, et puis aussi les problèmes d'impartialité (l'ICANN est très pro-américaine).
Mais il doit bien y avoir moyen de créer un organisme à peu près indépendant ... non ? (pas comme Microsoft qui essaye d'imposer son système pour les mails ...)
Je me demande juste qu'est-ce qui empêcherait les devs du kernel d'intégrer des bouts de code en GPL v3 ? La GPL v3 oblige-t-elle à ce que tous les bouts de code liés soit aussi sous GPL v3 minimum, ou GPL tout court ? Car à ce moment là, on pourrait mélanger les deux, même si les devs modifiant du code sous la v3 seraient obligés de coller à cette licence pour la suite.
Même si ce n'est pas du ogg/vorbis, c'est quand même super plaisant d'arriver sur un site, de cliquer, et de pouvoir écouter tous les extraits en ayant un OS standard avec un navigateur standard ! Ça marche tout de suite, pas la peine de bidouiller, c'est vraiment sympa ! Je parle du site de la Fnac là, pas de Virgin.
Alors :
1) les "conneries embedded" c'est la manière STANDARD d'intégrer une musique/vidéo dans une page web
2) ca fait plus de 6 mois que le WMV est un STANDARD ISO, et depuis septembre je les lis sans problème sur mon ppc
3) mettre des plugins Flash pour lire une vidéo est la manière la plus débile et lourdre d'intégrer un média à une page web
4) Flash ne file les docs que quelques temps après avoir sorti son player, et plus elles sont livrées sous des conditions innacceptables pour le libre : obligation de mettre "Export Flash (c) (tm)" pour l'export, et INTERDICTION de fabriquer un player ! Gnash est dans l'illégalité...
Alors j'emmerde Youtube et compagnie (même si effectivement après quelques bidouilles on peut lire le .FLV) et je préfère largement la méthode "classique" (mais malheureusement largement abandonnée aujourd'hui à cause des merdes que sont IE et WMP).
Les instructions SIMD ne sont pas du tout inutiles !
Pour l'arrivée de chaque technologie, ca doit être :
- MMX : avec le Pentium du même nom
- SSE : avec le P3 (il me semble)
- SSE2 : avec le P4
Je peux te dire que sans MMX et consorts, tu ne pourrais lire aucune vidéo à plus de 2 fps, ni jouer à aucun des jeux modernes, ni avoir un Xorg à peu près rapide dès qu'on mélange un peu plus que des carrés de couleur unie.
Tu ne les "vois" peut-être pas au jour le jour, car la plupart des opérations qu'on trouve "lentes" aujourd'hui, c'est quand les ressources ne sont pas limitées par le processeur, mais par les entrées/sorties (disque dur lent, mémoire lente, etc ...) ou alors par la conception plus que douteuse de certaines applis (problème au niveau du code, donc de l'homme ...). Mais pour tout ce qui est calcul intensif sur des données demandant le même genre de calcul, c-a-d tout ce qui est parallélisable, ça aide beaucoup.
Je trouve bizarre que tu apparentes le 2eme cas à un DRM : un "DRM" qui marche lors de l'achat seulement et après te laisse faire ce que tu veux, bah .... c'est juste une téléchargement normal : le vendeur te laisse télécharger le fichier, et après tu en fait ce que tu veux.
Là ou tu semble voir un DRM, c'est pour le point "te laisser télécharger", non ? Et biens je te dirais que c'est le même problème que pour tout le reste : si tu n'a pas envie que quelqu'un ait (et donc puisse copier) ce que tu produits, tu n'as qu'à pas le distribuer ! Et que donc tu n'autorises le téléchargement de ton produit qu'à des gens qui t'ont donné ce que tu demandais en échange (de l'argent, généralement). Ce que font à peu près tous les sites de vente en ligne, que ce soit pour de l'immatériel ou non, sans avoir besoin de "DRM".
La vente en ligne aujourd'hui se porte très bien sans "DRM" : elle utilise la cryptographie pour sécuriser les connexions, et utilise un tiers de confiance pour valider les paiements (généralement, la banque). Pas d'histoire de gestions des droits la dedans, ni de Mesure de Protection Technique.
Je ne pense pas qu'il soit question d'une conspiration, mais plutot d'un constat. Si on lit ça http://lxr.linux.no/source/Documentation/stable_api_nonsense(...) on peut en extraire : "Simple, get your kernel driver into the main kernel tree". Pour moi ça veut quand meme dire que torvald, il préfére que l'on mette son code dans la branche principale. Mais bien entendu je trouve ça trés bien qu'on puisse inclure son driver dans la branche principale.
Oui, je suis d'accord que c'est une forte incitation à mettre son code dans la branche principale. Mais je réagissais au fait que TImaniac dise que Linus voudrais "tout maîtriser" et "forcer les gens", ce qui est un tout petit peu exagéré...
Peut être que la norme POSIX a été faite pour qu'un programme codé pour cette norme fonctionne partout et toujours où celle ci existe ? Et je pense que c'était ça le fondement de son propos. Faire qu'un driver un fois codé pour linux fonctionne le plus longtemps possible.
Oui, mais comme j'ai précisé plus haut, l'interface POSIX est une interface utilisateur et plus haut niveau. Les interfaces driver sont assez différentes de cela, et à mon avis c'est difficilement transposable.
Bah si elles sont si pourries ces API pourquoi ils les ont mises dans le kernel ? Et tu entends quoi par des API stables ?
OK j'exagère en disant pourri, mais des fois les devs se rendent compte que les choix qu'ils ont fait à une époque n'étaient pas les bons, et qu'il faudrait changer d'API. Et par API stable, j'entend .... qu'elles change pas du tout ?
Pour moi un des gros problémes des API qui bougent, c'est simplement le fait que quelques fois tu es un gros noobs et tu achétes du matériel compatible avec un driver libre. Ce driver se trouve dans la branche X du noyau et toi t'as la version X-2 sur ton ordi. Comment tu fais ?
- Tu upgrades ta distro ? : T'as pas forcément envie, ça marche bien et t'as pas envie de tout casser.
- Recompiler ton noyau, faire un package , toussa. : Pas trés simple et ça fou les boules de recompiler son noyau.
- Récupérer les sources du module nécessaire sur le site du projet la version pour ton noyau X-2 : Pas trés simple et en plus on a pas forcément les derniers bugfix ce qui peut se révéler assez génant.
Oui c'est vrai que c'est assez embêtant, mais c'est souvent dû au fait que les drivers arrivent beaucoup plus tard que la sortie sur le marché du matos, car les devs n'ont soit pas les docs (ou pas assez tôt), et alors ils sont obligés de faire du reverse engineering, et ça prend du temps.
Oui, faire des API stables et s'y tenir c'est difficile et ça prend du temps, chose que n'a pas toujours la communauté. Si les constructeurs matériel jouaient plus le jeu du libre, je pense qu'on aurait pas ce genre de problème et qu'on pourrait avoir des APIs changeantes sans problème.
PS : T'énerve pas, c'est pas la fin du monde. On parle juste d'un programme informatique
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
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.
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...
[^] # Re: Bravo !!!!
Posté par benoar . En réponse au journal Erudissey. Évalué à 2.
- j'ai pas les symboles de débugage, va falloir recompiler cairo (et mon petit G4 800 se traine un peu)
- cairo marche déjà pas trop mal avec GTK2, donc je suppose que le problème vient de gecko (ou Xorg), ce qui m'amène à :
- je suis un peu malade du code de gecko et de X (j'avoue n'avoir que survolé gecko, mais je suppose que c'est pareil que Xorg : j'en peu plus tellement le code est lourd et imbitable)
- ma plate-forme (ppc) et mon système sont un peu spéciaux, je bidouille plein de trucs, donc je ne me retrouve jamais dans les mêmes situations que les devs ce qui fait que souvent les problèmes viennent d'autre part sans que je puisse jamais savoir si le problème va être reproductible (par exemple les lenteurs de X sur ppc sont surement du à la non optimisation des routines pour le frame buffer : personne ne s'en rend compte sur x86 car c'est optimisé MMX et que tout est fait dans l'ALU classique sur ppc. J'ai essayé quelques optimisations, mais ça a pas mené à grand chose vu que la manière dont est architecturé Xorg fait que le code vectoriel dépend beaucoup de la vitesse du bus mémoire et qu'à ce niveau, l'Altivec est pourri. Et que mes tentatives à une époque avec E17 n'ont rien donné vu que le patch que j'ai envoyé n'a jamais atteint le CVS vu que tout le monde s'en branle du ppc)
Bon alors je pourrais laisser le boulot aux devs de cairo ... mais ça me semble un peu injuste vu que j'aurai peut-être les compétences pour le faire. Enfin bon oui, je pourrais rester au simple role de testeur...
[^] # Re: Bravo !!!!
Posté par benoar . En réponse au journal Erudissey. Évalué à 1.
Après un petit oprofile, chez moi c'est cairo qui crame la quasi-totalité du temps CPU. Et vive le vectoriel !
[^] # Re: Authentification, oui mais non
Posté par benoar . En réponse au journal Somutions contre le SPAM ?. Évalué à 1.
C'est vrai qu'il y a quelques problèmes de centralisation de la responsabilité de qui a le droit d'avoir un nom de domaine ou pas, et puis aussi les problèmes d'impartialité (l'ICANN est très pro-américaine).
Mais il doit bien y avoir moyen de créer un organisme à peu près indépendant ... non ? (pas comme Microsoft qui essaye d'imposer son système pour les mails ...)
# Compatibilité GPL v2/v3 ?
Posté par benoar . En réponse au journal Solaris sous GPLv3. Évalué à 1.
# Ca fait plaisir quand même
Posté par benoar . En réponse au journal Fnac et Virgin vendent des mp3 !. Évalué à 1.
[^] # Re: Flash ?
Posté par benoar . En réponse au journal Vous connaissiez cette chanson de Stallman ?. Évalué à 7.
1) les "conneries embedded" c'est la manière STANDARD d'intégrer une musique/vidéo dans une page web
2) ca fait plus de 6 mois que le WMV est un STANDARD ISO, et depuis septembre je les lis sans problème sur mon ppc
3) mettre des plugins Flash pour lire une vidéo est la manière la plus débile et lourdre d'intégrer un média à une page web
4) Flash ne file les docs que quelques temps après avoir sorti son player, et plus elles sont livrées sous des conditions innacceptables pour le libre : obligation de mettre "Export Flash (c) (tm)" pour l'export, et INTERDICTION de fabriquer un player ! Gnash est dans l'illégalité...
Alors j'emmerde Youtube et compagnie (même si effectivement après quelques bidouilles on peut lire le .FLV) et je préfère largement la méthode "classique" (mais malheureusement largement abandonnée aujourd'hui à cause des merdes que sont IE et WMP).
[^] # Re: Merci pour tout ces commentaire
Posté par benoar . En réponse au journal utilité du i386. Évalué à 0.
Pour l'arrivée de chaque technologie, ca doit être :
- MMX : avec le Pentium du même nom
- SSE : avec le P3 (il me semble)
- SSE2 : avec le P4
Je peux te dire que sans MMX et consorts, tu ne pourrais lire aucune vidéo à plus de 2 fps, ni jouer à aucun des jeux modernes, ni avoir un Xorg à peu près rapide dès qu'on mélange un peu plus que des carrés de couleur unie.
Tu ne les "vois" peut-être pas au jour le jour, car la plupart des opérations qu'on trouve "lentes" aujourd'hui, c'est quand les ressources ne sont pas limitées par le processeur, mais par les entrées/sorties (disque dur lent, mémoire lente, etc ...) ou alors par la conception plus que douteuse de certaines applis (problème au niveau du code, donc de l'homme ...). Mais pour tout ce qui est calcul intensif sur des données demandant le même genre de calcul, c-a-d tout ce qui est parallélisable, ça aide beaucoup.
[^] # Re: C'est bien triste...
Posté par benoar . En réponse au journal Logiciels propriétaires : bientôt les DRM ?. Évalué à 6.
Là ou tu semble voir un DRM, c'est pour le point "te laisser télécharger", non ? Et biens je te dirais que c'est le même problème que pour tout le reste : si tu n'a pas envie que quelqu'un ait (et donc puisse copier) ce que tu produits, tu n'as qu'à pas le distribuer ! Et que donc tu n'autorises le téléchargement de ton produit qu'à des gens qui t'ont donné ce que tu demandais en échange (de l'argent, généralement). Ce que font à peu près tous les sites de vente en ligne, que ce soit pour de l'immatériel ou non, sans avoir besoin de "DRM".
La vente en ligne aujourd'hui se porte très bien sans "DRM" : elle utilise la cryptographie pour sécuriser les connexions, et utilise un tiers de confiance pour valider les paiements (généralement, la banque). Pas d'histoire de gestions des droits la dedans, ni de Mesure de Protection Technique.
[^] # Re: miam miam le bon troll
Posté par benoar . En réponse au journal Gtk, un toolkit qu'il est pourri (on est pas vendredi). Évalué à 2.
http://web.archive.org/web/20010823142824/http://lists.eazel(...)
(Obligé de chopper ça dans archive.org, puisqu'Eazel n'existe plus après son rachat par Novell, je crois)
[^] # Re: Faut pas exagerer...
Posté par benoar . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 1.
Oui, je suis d'accord que c'est une forte incitation à mettre son code dans la branche principale. Mais je réagissais au fait que TImaniac dise que Linus voudrais "tout maîtriser" et "forcer les gens", ce qui est un tout petit peu exagéré...
Oui, mais comme j'ai précisé plus haut, l'interface POSIX est une interface utilisateur et plus haut niveau. Les interfaces driver sont assez différentes de cela, et à mon avis c'est difficilement transposable.
OK j'exagère en disant pourri, mais des fois les devs se rendent compte que les choix qu'ils ont fait à une époque n'étaient pas les bons, et qu'il faudrait changer d'API. Et par API stable, j'entend .... qu'elles change pas du tout ?
Oui c'est vrai que c'est assez embêtant, mais c'est souvent dû au fait que les drivers arrivent beaucoup plus tard que la sortie sur le marché du matos, car les devs n'ont soit pas les docs (ou pas assez tôt), et alors ils sont obligés de faire du reverse engineering, et ça prend du temps.
Oui, faire des API stables et s'y tenir c'est difficile et ça prend du temps, chose que n'a pas toujours la communauté. Si les constructeurs matériel jouaient plus le jeu du libre, je pense qu'on aurait pas ce genre de problème et qu'on pourrait avoir des APIs changeantes sans problème.
Oui désolé, merci d'avoir calmé le jeu !
[^] # Re: Faut pas exagerer...
Posté par benoar . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 5.
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.
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 ...
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.
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.
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 ?
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.
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é".
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.
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.
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.
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.
[^] # Re: Faut pas exagerer...
Posté par benoar . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 10.
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.
Justement, ce qu'on dit c'est l'interface utilisateur <-> kernel est plus ou moins "standard" (de fait), contrairement aux API internes.
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.
Ha oui, bien sûr, la conspiration contre les petits développeurs et les constructeurs ...
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.
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.
Ils ne perdent pas leur temps à adapter les drivers puisqu'ils devront bien s'adapter un jour à cette nouvelle API !
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.
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.
Encore du n'importe quoi, les changements sont généralement documentés.
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.
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
[^] # Re: clarté des brevets
Posté par benoar . En réponse au journal Relecture attentive des brevets... Évalué à 2.
[^] # Re: clarté des brevets
Posté par benoar . En réponse au journal Relecture attentive des brevets... Évalué à 3.
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.
[^] # Re: Les "tenors" de mes deux
Posté par benoar . En réponse à la dépêche Tribune Libre, ténors de l'informatique libre. Évalué à 3.
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 ?
# "Innocent" Novell
Posté par benoar . En réponse au journal La suite du feuilleton Microsoft/Novell. Évalué à 7.
ç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) :
- Que de toutes façons, Mono n'enfreint de de brevets de Microsoft, c.f. la Q8 :
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...
[^] # Re: Pour résumer l'article..
Posté par benoar . En réponse au journal La Java de Sun est libre. IBM n'est pas content.. Évalué à 2.
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).
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par benoar . En réponse à la dépêche Mono passe en version 1.2. Évalué à 2.
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.
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par benoar . En réponse à la dépêche Mono passe en version 1.2. Évalué à 1.
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.
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par benoar . En réponse à la dépêche Mono passe en version 1.2. Évalué à 3.
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.
[^] # Re: Y en a qui ont pas froid aux oreilles
Posté par benoar . En réponse à la dépêche Mono passe en version 1.2. Évalué à 5.
Ho ! Alors j'ai du rêver en lisant ça :
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).
# Y aller petit à petit
Posté par benoar . En réponse à la dépêche La pétition racketiciels dépasse les 10 000 signatures. Évalué à 9.
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...
[^] # Re: Quand ?
Posté par benoar . En réponse au journal Nous ne sommes pas le 1er avril. Évalué à 2.
[^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?
Posté par benoar . En réponse au journal Support matériel parfait sous OpenBSD. Évalué à 4.
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).
[^] # Re: Pas de blob propriétaire avec un wifi intel 2200 ?
Posté par benoar . En réponse au journal Support matériel parfait sous OpenBSD. Évalué à 2.
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...