Il peut toujours la réclamer mais c'est pas pour ça que ca va se faire.
Il peut exiger que ca se fasse pour que son nom ne soit plus associé avec le module dans le kernel (il reste toujours dans les contributeurs du code, mais sort des contributeurs du kernel). Après ca la personne qui réintroduit le code prend sa place vis à vis du kernel.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras.
a - PWC fonctionne en stand alone et PWCX fonctionne en stand alone (moyennant bidouilles) Celà ne constitue donc pas une violationd e la GPL
b - La GPL authorise des lib proprios a lier des applis GPL et des libs GPL a lier des applis ou ldes libs proprios a condition que les parties propriétaires soient inhérentes au système. Comme il s'agit du Kernel et de modules du kernel je pense que l'on peut raisonablement penser que l'on est dans un cas ou c'est inhérent au système. Donc ca ne viole toujours pas la GPL.
c - Le link se fait via un hook qui permet de charger un décompresseur video. Sans ce hook aucun decompresseur ne peut être chargé (les decompresseur fonctionnent comme des inits qui passent la webcam d'un mode a un autre), qu'il soit GPL ou non. Il est très facile (même si ca n'existe pas vu que c'ets el fonctionnement de base) de créer un module GPL qui ferait du RAW (IE n'apellerait rien et ne chargerait aucun compresseur). Donc ca ne constitue pas une violation de la GPL.
C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique
Niveau cohérence en effet c'est assez fort :
- Ca fait plus de 3 ans que c'est comme ca.
- Il y a un paquets d'exemples de hooks qui servent a charger aussi des drivers/modules propriétaires (Au hasard les drivers XFree/AGP de chez Nvidia, mais il y en a d'autres)
- Enlever ce morceau n'apporte rien au noyeau, ni au niveau architectural, ni au niveau perf, ni au niveau legal. Le seul point de doute pourrait être levé par un driver GPL qui ne fait rien (CF c- plus haut).
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
Ne nous y trompons pas, on a affaire a une guerre d'ego. D'un coté une personne qui a décidé pour une raison X ou Y que le module ne lui plaisait pas, et de l'autre une personne qui n'etant plus sous NDA decide de quand même garder les sources fermées pour un motif noble ou non.
Ce qui m'embete le plus c'est que j'ai déjà vu ce type de comportement... Chez XFree86.
Il faut insister un peu.
Si ils invoquent le piratage comme motif, dire que vous voulez le même CD et que donc leur argument ne tient pas. Là ils peuvent difficilement refuser.
Quand vous ramenez un CD pour la troisième fois en faisant un vrai scandale a chaque fois, et que tout le monde dans le magasin y compris le manager sait qui vous êtes ils reprennent les CD. Et vite encore.
je dirais que ce qui manque le plus c'est la possibilité de citer un commentaire dans un message que l'on envoit au posteur dudit commentaire. Ca permettrait de déporter les discussion techniques/les trolls un peu trop violent/les inimitiés naissantes ailleurs que dans les commentaires d'une news.
Peu de chance. Ca ressemble plus a une autentification de domaine. Sans les activeX qui vont bien ca risque de pas passer.
Reste à voir la config dans le script de config automatique auquel IE ne doit pas manquer de se referer. Mais si les admins sont bons il y a peu de chance...
Cela laisse supposer que tout le savoir du fabricant réside dans son pilote.
Non, mon argument est que compte tenu du fait que les pilotes emulent un grand nombre de fonctions, il est beaucoup plus simple de comprendre ce que font les différents appels matériels.
Ce n'est donc pas avec que l'on va voler la technologie du fabricant.
Comme les APIs sont émulés en utilisant de facon simpliste des fonctions plus évoluées, ca aide au contraire beaucoup a comprendre l'ensemble du pipeline et sa compisition.
Il me paraît évident qu'une équipe avec des connaissances à jour, spécialisée en cartes graphiques, et focalisée sur ce sujet précis peut faire de même et obtenir très vite de très bons résultats.
Le gros problème des cartes graphiques est qu'elles sont faites pour fonctionner en DSP, soit donc efectuer plusieurs opérations simultanément (bon en fait souvent plusieurs fois la même opération, bien que les shaders ait pas mal changé la donne a ce niveau). Toute personne qui ayant le code source s'est amusé a faire un débuggage d'un programme qu'il connaissait et dont il avait le source sait a quel point le multithreading peut être usant. Suivre le déroulement d'un programme sur plus de 4 threads en simultané demande des capacités zen et un nivau de concentration assez énorme.
Une fois que l'on sait ca, il est assez facile de se rendre compte que surveiller 16 pipelines de 8 instructions doubles en DSP (donc 256 opérations simultanées sur la puce) d'après des bribes de pilotes et un affichage a l'écran c'est assez violent a faire quand même. Si on ajoute à celà que l'instruction "simple" de lookup texture peut être utilisé soit pour connaitre la valeur d'un pixel de facon a afficher la texture, soit pour servir de map d'éclairage, soit pour initialiser des shaders on comprend que ca fait beaucoup de tests et de spéculations pour pas grand chose niveau résultat.
Il est tout-à-fait possible pour un fondeur de puces de procéder à la rétro-ingéniérie physique d'un circuit déjà intégré !
J'ai joué a celà sur des puces 8 bits aussi. Mais une fois de plus on parle ici de puces de plus de 50 millions de transistor, gravées au plus fin, réparties sur 8 a 16 couches en recto verso. Il faut donc les ouvrir sans rein casser, les éplucher feuille a feuille (toujours sans rien casser) et ensuite les transmettre a une photographe spécialiste dans uen salle blanche d'indice monstrueux pour qu'il fasse l'inverse de ce qui marche déjà moyennement(yields de 10% pour les processeurs "simples") a savoir faire un cliché grand taille des lamelles qu'on lui donne. Rein que cette dernière étape, au prix de l'heure de mobilisation de salle blanche risque d'être très couteux très vite.
Ces arguments sont valables pour des secteurs de pointes comme les cartes graphiques par exemple, pas pour d'autres périphériques telles que les imprimantes, souris, etc.
Je dirais même plus, ces arguments ne sont valables que pour les périphériques ne pouvant physiquement pas bénificier d'une interface unifiée pour les accès et les appels matériels. C'est a dire a peu de chose près : les cartes graphiques et les carte sd'aquisition multistandards haut de gamme. Même une carte son très haut de gamme qui fournit 4 interface type wave et une interface midi en accès matériel n'a pas vraiment besoin de jouer les chochottes par rapport au contenu de son driver de toute facon c'est une norme ! On a juste besoin de connaitre l'adresse et éventuellement l'interruption a appeler pour que ca marche. Le code est souvent déjà écrit.
Cela se faisait avant !
Tout a fait. J'ai encore le schéma de montage complet de la vieille télé de mes parents. Mais pour être exact tout le monde le faisait avant, aujourd'hui plus personne ne le fait. Il s'agirait donc de convaincre TOUS les intervenants du monde des cartes graphiques de relacher les sources de leurs pilotes le même jour a la même heure pour qu'ils acceptent. Bien entendu il faudrait aussi qu'il y ait un moyen de vérifier que les sources relachées sont complètes, a jour et compilent. Ca va être dur...
L'ancien muvo2 était démontable pour en extraire le microdrive au format CF2 qui permet sur les appareils photos haut de gammes de mitrailler en 6Mo format raw. Et c'est d'ailleurs pour celà qu'il se vendait si bien.
Malheureusement la nouvelel version ne permet plus d'extraire le disque facilement.
En tout cas pour ce qui est de là compatibilité Linux pas de problème, mais en ce qui concerne la compatibilité avec des oreilles humaines standards elle est jugée faible, voire insuffisante.
C'est sérieux ou c'est de la pub et ne sortira que dans 1 an?
C'est très sérieux si tu parles de la mise a jour d'OpenGL. Ati compte bien raffler les perfs OpenGL a ses concurents (ici c'est Wildcats qui est visé) sur les applications pros. Si au passage ils peuvent ramener les perfs de la X800 au niveau de celles de la 6800 sous Doom3 je suis sur qu'ils ne se priveront pas.
Si tu parles de drivers Fire GL sous Linux. Il s existent déjà pour 90% des cartes et 100% des cartes sorties par ATI (ie créées après le rachat de Fire GL)
Il y a quand meme des outils qui permettent d'installer les drivers sur des radeons mobiles
Oui mais ca part du principe que le design utilisé par le constructeur est proche de celui de référence fourni par ATI. Et ben des fois il y a des surprises, surtout dans les cas ou sur les puces IGP la mémoire de la CG est en fait celle de l'ordi.
En plus c'ets un peu du bricolage...
Cependant, la vie reste globalement moche, et je ne perds pas de vue que si l'on ne râle pas, on n'obtient rien.
La question est plus à mon sens de savoir quand raler. ATI n'est certes pas le meilleur contributeur à la démocratisation de Linux (et loin s'en faut), mais ils ont tout de même l'air bien décidé a faire quelquechose. Il sont parit en phase de réécriture des drivers avec réimplémentation complète de l'OpenGL pour bien sur de meilleures performances sous windows, mais aussi pour une plus grande facilité de mise a jour et d'écriture des drivers sous Linux. Et si on les laissait finir pour voir ce que ca donne avant de demander plus ?
On pourrait au moins attendre que la nouvelle génération de drivers OpenGL soit sortie sous Windows avant de hurler "Et Linux Alors ?"
Ou alors on pourrait attendre qu'il y ait au moins deux jeux qui justifient la création de tels drivers, parceque les gens qui hurlent disent tous la même chose sur les forums. On n'entend pas de "tel jeux est injouable/trop lent/trop lourd sous Linux" mais des je fais seulement xxxx fps sous GLXGears. Et ça, ça a le don de m'ennerver un peu.
Argument des constructeurs on ne peut plus falacieux.
Si tu veux avoir une excellente vu d'ensemble de l'interieur des puces de CG il te suffit d'aller trainer du coté de HardwareFR.
Tu m'excuseras je coupe le reste parceque ta comparaison n'est pas valable.
On est passé d'un modèle statique (cracheur de poygone + textures avec lissage) a un modèle dynamique. La première génération s'apellait T&L (Transform and Lightning) Grosso modo les cartes ne faisaient plus seulement du rendu "brutal" mais devenait capable d'effectuer des opérations complexes sur les polygones (placement, rotation, éclairage) déchargeant ainsi le CPU d'autant.
On est aujourd'hui passé a un mode de shaders, des suites de micro instructions effectués soit sur un ensemble de vertex (une ligne d'un polygone) soit sur les pixels d'une texture. Pour des raisons de "place" dans le GPU Il n'était pas question d'empiler les transistors pour avoir d'un coté une archi statique, de l'autre une archi T&L et enfin une suite d'archis supportants les shaders de différentes versions pour Directx et OpenGL.
La bonne approche consiste a faire le mieux possible les unités les plus évoluées en émulant les autres quitte éventuellement a rajouter un peu de logique dans le pro pour pallier quelques manques ou faiblesses des perfs par émulation.
En d'autres termes dans un pilotes de cartes graphiques moderne, il y a les Paths Shaders 2, les paths shaders 1.x , les paths T&L et les paths statiques, avec a chaque fois un max d'astuce de programmation pour optimiser l'émulation le plus possible. C'est çà ou faire exploser le nombre de transistor de la puce (et aujourd'hui même SGI fait comme ca sur les CGs des workstation...)
Contrairement a une archi CPU classique on a pas une interface de programmation normalisé et de niveau relativement élevé (si tant est que l'on puisse parler de haut niveau pour de l'assembleur par opposition au byte code) , mais on a une foule d'interfaces qui passent par des chemins différents et qui sont aussi proche du GPU core que possible. Dans un cas on a le manuel utilisateur dans l'autre des plans détaillés pris sous plusieurs angles différents, détaillant composant par composant le chemin pris par telle ou telle instruction haut niveau (au sens appels OpenGL/DirectX cette fois).
Du fait de la versatilité des applications graphiques et des besoins très différents que peuvent avoir les différents intégreurs/éditeurs les fabriquants de cartes graphiques ne peuvent pas "fermer" leur carte dérrière une interface unique comme c'est souvent le cas pour les autres cartes ou processeurs. D'ou leurs craintes de voir les sources de leurs drivers entre les mains d'un concurrent.
Sauf que :
1) Il sont déjà en train de réécrire le support OPenGL complet de leur puces modernes de facon a pouvoir fournir une acceleration de meilleure facture sous windows d'une part et surtout sous Linux ou leur produit haut de gamme (FireGL) commencent à avoir du mal a suivre autre chose que les applications leaders (Maya par exemple)
2) Pour les puces inférieur a la 8500 ils ont toujours dit qu'ils fourniraient une partie des specs mais qu'ils ne feraient jamais de drivers Linux.
3) Toutes les Puces X800 et dérivées stand-alone ont des drivers en cours de dev sous Linux (voir déjà opérationnels pour les FireGL)
4) Ce ne sont pas eux qui font les cartes sur lesquels sont installés les puces radeon mobiles, ils fournissent juste un desgin board et un kit de dev drivers. Il ne fournissent d'ailleurs pas non plus les drivers windows pour chipset mobile.
5) En ce moment ils vendent par centaines de milliers les X800s aux OEM (Dell et Sony notamment a qui NVidia sort par les yeux.) Alors que Nvidia a les pires yields qui soient sur la 6800 extreme (quelques centaines d'unités produites). Donc que l'ensemble de la communeauté se mobilise pour ne plus acheter leur produit ils s'en moquent un poil en ce moment.
6) Les gens qui ont vraiment besoin des capacités 3D ont accès aux drivers FireGL pour n'importe quelle cartes, même si il faut parfois utilise run serveur X propriètaire, de toute façon les applications comme Maya ou les applis de CAD professionelle utilisent des drivers propriétaires optimisés souvent dévellopés par le vendeur de la station de travail en collaboration avec l'éditeur du programme.
7) ATI est en train de gagner la guerre des cartes graphiques pour Power User/Gamers fou. Libérer les drivers maintenant ne leur viendrait même pas a l'idée (Un pilote n'est pas seulement un programme informatique stand alone, en l'analysant on peut souvent en apprendre beaucoup sur les choix technologiques et l'architecture du concurrent).
Bref tout ca pour dire que je ne signerais pas la pétition et que je continuerais a acheter du matériel ATI encore un moment (Même si je reconnais beaucop de qualités à la 6800, il y a encore trop de choses bloquantes pour que je me tourne sérieusement vers cette carte.)
Les chances d'avoir deux fichiers qui possèdent le même hash MD5 et SHA-1 sont sans doute assez faibles. Par conséquent, si l'on trouve un fichier correspondant au deux empreintes alors il y a encore plus de chance que le fichier trouvé est le fichier qui correspond au message d'origine.
MD5 et SHA-1 ne sont pas facilement decryptables, Ce sont des hashs dont le but dans la transmission de données est d'assurer l'authenticité d'un fichier (eventuellement en clair). Pour chiffrer les données et faire des sigantures autant se rabattre sur des systèmes à clefs publiques beaucoup plus adaptés a ce genre de choses.
La double empreinte est peut être un afaiblissement de la sécurité au final.
En terme de sécurité, surtout si le message est déjà en clair (par exempel les RPMs de chez Mandrake) pas vraiment non.
t'a l'air de t'y connaitre donc j'en profite pour une petite question : est-ce que cette faiblesse de SHA-0 existe aussi dans les nouveaux SHA-256 ; SHA-384 et SHA-512 ?
C'est vrai j'ai l'air ? Chouette je vais pouvoir monter d'un cran mon pipomêtre.
Non sans rire, il s'agit là d'accadémiciens de très haut niveau qui ont découvert une faille en 1998 et une deuxième en 2004 dans un protocole considéré comme obsolète par ses inventeurs depuis 1994, je suis absolument pas au niveau de commenter leur recherche ou d'extrapoler sur les effets de bords.
En ce qui concerne les autres SHA, pour l'instant rien n'a été trouvé. Mais la première faille (celle du bit neutre trouvée en 1998) voit ses chances de se produire réduire au fur et a mesure que la force augmente. En plus les algos SHA-256 et plsu ont été modifiés par rapport a SHA-1 lequel était déjà une correction de SHA-0 (Le RSA savait par preuve mathématiques qu'il y avait une faille dans SHA0, mais ils ne savaient pas ou et quoi). Ceci étant je n'ai pas entendu parler de la moindre alerte concernant les SHA > 0, mais il y a des rumeurs sur SHA1. Si elles sont fondées alors le problème pourrait bien remonté sur les autres SHA...
SHA0 était une variante de MD4, il est donc possible que les failles de SHA0 soient venus de MD4 et que celles-ci soient aussi remontés dans MD5 de façon plus ou moins abbatardie par les modifs de l'évolution MD4->MD5.
car si il suffit du couple signature + taille pour securiser un peu plus, c'est bon non ?
Bon déjà ca n'est aps vraiment un signature, c'est un hash.
Et ensuite la taille pour la certifier, il va bien falloir a un moment ou a un autre la hasher ou la signer non ?
Quelle serait la probabilité pour qu'un faux mot de passe (ie. même empreinte) soit à la fois "compatible" md5 et sha-1 ?
Là on peut dire 0. Pour être exact il y a une chance sur 2^64 soit environ une chance sur 16 000 000 000 000 000 000. (16 milliards de millards). C'est plutôt faible non ?
Par contre réussir a génrer un "faux fichier" possédant a la fois le même MD5 et le même SHA-1 qu'un autre doit être monstrueux. Et le faux fichier doit avoir au final une taille assez importante, probablement plusieurs To.
Donc si vous voyez un fichier avec le bon SHA-1 et le bon MD5 mais qui fait plus de 4 Terra Octets de données, ne le téléchargez pas ! Si ca se trouve il a été spoofé !
On n ese laisse pas aller a la paranoia, on est encore très loin du moment ou ca va devenir dangereux.
Pour l'instant un super calculateur Bull a reussit en 80 000 heures de calculs CPU a générer deux fichiers qui on le même SHA0. L'algorithme est de complexité 2^51.
On est encore très loin du moment ou on va pouvoir remplacer un fichier existant par un autre avec un trojan en rajouter des données "poubelle" a la fin du fichier pour obtenir le même md5.
Bref remplacer le fichier ftp.rpm par un virus en gardant le même MD5 c'est pas pour tout de suite.
Il y a définitevement une faille, des gens plus ou moins bien intentionnés vont probablement s'en servir un jour, mais pas avant plusieurs années.
Vous pouvez continuer a utiliser SHA0 un petit moment, et ceux d'entre vous qui paniquent peuvent soit faire un couple SHA0( ou 1)/MD5 soit faire du MD5+Signature du binaire.
Ceux qui ont pris l'habitude de signer des hashs pour une double sécurité, devraient commencer a songer sérieusement a signer les binaires ou a signer des couples de hashs.
Et bien avec Xlib, le truc pas top, c'est que c'est le programmeur lui-meme qui doit gerer le multithreading pour pallier ce probleme. Alors que XCB etant asynchrone, je pense que la seule maniere de gerer ca correctement est de laisser la librairie gerer ca.
En fait la XLib n'ets pas capable de gerer plusieurs instances de certains paramètres. Par exemple les propriétés d'une fenêtre ne peutvent exister qu'en un seul exemplaire, XGetWindowsProperties va donc entrainner un blocage de toutes les requètes qui ont besoin des propriétés d'une fenêtre ou des fenêtres racines. Celà implique que si on fait une requête sur la fenêtre racine, plus aucune requête de propriété sur les fenêtres ne peut avoir lieu. L'ensemble des applications est bel est bien bloqué jusqu'à ce que la XLib est finit de parser les propriétés et d'agir en conséquence.
Par contre la mauvaise nouvelle est que sous XCB une grosse partie de la synchro et de la gestion des threads est encore faite a la main. Les cookies doivent être allouées et traités par le dev lui même.
Plus ou moins. En fait, utiliser XCL permet de remplacer XLib par la meme interface (les signatures de fonctions sont identiques).
En fait XCL n'existe plus vraiment, il s'agit désormais d'une version modifiée de la XLib pour laquelle XCB fait un peu effet de proxy. Il est ainsi possible de passer outre les problèmes vu plus haut.
Ce qui est mis en avant c'est un système qui t'empèche d'utiliser une idée brevetée sans le savoir. En d'autres termes il y a censure automatique. Dans mon univers il existe un système qui permet de louer des licenses pour les systèmes brevetés, mais personne ne se lance dans le processus lent d'achat ou d elocation de license pour un dessin fait au tableau ou pour une explication simple.
- Le NX Bit : la technologie qui permet de donner les droits en execution a un segment mémoire, en d'autres termes on définit une zone mémoire comm étant non executable (data only) et il devient impossible de demander au CPU d'executer quelques intructions que ce soit dans cette zone. Cette technologie n'existe pas sur architecture x86.
- La protection de pile : Qui interdit au gestionnaire de mémoire et a l'OS de jumper la pile en execution. En d'autres termes il devient impossible de placer des instructions au sommet de la pile et d'attendre que le programme l'execute.
C'est la deuxième technologie qui pose problème sur les logiciels mal codés. En effet certains prog n'hésite pas a accumuler le code sur la pile et à l'executer après. Bien entendu cette façon de faire entrainne une faille de sécurité dans 90% des cas.
La Xlib dispose de plusieurs type d'appels. Certains fonctionnent en mode assynchrone, d'autres en mode synchorne mais sont bloquant pour l'appli et d'autres enfin sont bloquants pour l'ensemble du serveur.
Le problème étant que les fonctions qui font appel aux propriétés de la fenêtre racine (profondeur de couleur, renvoit de segments bitmaps pour fausse transparence, positionnement automatique de la fenêtre au pixel de valeur absolue le quart de l'écran etc.) bloquent l'ensemble de la XLib qui va refuser toutes les autres demandes. Le serveur lui pendant ce temps là va se tourner les pouces.
Comme les effets nécessitant des appels bloquant ssont de plus en plsu nombreux (bords de fenêtres arrondis, fond transparent ou translucide, lissage de polices, positionnement automatiques de fenêtres etc.) On imagine bien l'impact que celà finit par avoir.
La plupart des applis essayent de mettr eun maximum d'information en cache pour éviter d'avoir a refaire un lookup gourmand, mais là c'est la mémoire qui prend et il y a aussi un ralentissement des perfs...
Si le protocole est fait pour, pourquoi la Xlib ne le fait pas directement ?
Les equivalents XLib des solutions propriétaires sont assynchrones. En ce qui concerne la XLib de XFree, je parlerais bien de l'attitude et des réponses faites par le projet XFree a mes demandes et à d'autres pour le passage de la XLib en mode assynchrone, mais on va encore me traiter de trolleur.
Est-ce que le gain en performance s'observera uniquement sur les applis programmées pour XCB, ou alors aussi sur celles, pour Xlib, qui utilisent XCB via le pont ?
sans être vraiment avantagées au niveau vitesse, les applications XLib utilisant le pont auront au moins la gentilesse de ne pas bloquer les autres. En d'autres termes utiliser le pont plutot que la librairie native permettra de garder le serveur X disponible pour faire autre chose, même quand une requête XLib sera en cours d'execution.
[^] # Re: pwc vs pwcx
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Il peut exiger que ca se fasse pour que son nom ne soit plus associé avec le module dans le kernel (il reste toujours dans les contributeurs du code, mais sort des contributeurs du kernel). Après ca la personne qui réintroduit le code prend sa place vis à vis du kernel.
C'est tout ce qu'il demande.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 9.
a - PWC fonctionne en stand alone et PWCX fonctionne en stand alone (moyennant bidouilles) Celà ne constitue donc pas une violationd e la GPL
b - La GPL authorise des lib proprios a lier des applis GPL et des libs GPL a lier des applis ou ldes libs proprios a condition que les parties propriétaires soient inhérentes au système. Comme il s'agit du Kernel et de modules du kernel je pense que l'on peut raisonablement penser que l'on est dans un cas ou c'est inhérent au système. Donc ca ne viole toujours pas la GPL.
c - Le link se fait via un hook qui permet de charger un décompresseur video. Sans ce hook aucun decompresseur ne peut être chargé (les decompresseur fonctionnent comme des inits qui passent la webcam d'un mode a un autre), qu'il soit GPL ou non. Il est très facile (même si ca n'existe pas vu que c'ets el fonctionnement de base) de créer un module GPL qui ferait du RAW (IE n'apellerait rien et ne chargerait aucun compresseur). Donc ca ne constitue pas une violation de la GPL.
C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique
Niveau cohérence en effet c'est assez fort :
- Ca fait plus de 3 ans que c'est comme ca.
- Il y a un paquets d'exemples de hooks qui servent a charger aussi des drivers/modules propriétaires (Au hasard les drivers XFree/AGP de chez Nvidia, mais il y en a d'autres)
- Enlever ce morceau n'apporte rien au noyeau, ni au niveau architectural, ni au niveau perf, ni au niveau legal. Le seul point de doute pourrait être levé par un driver GPL qui ne fait rien (CF c- plus haut).
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
Ne nous y trompons pas, on a affaire a une guerre d'ego. D'un coté une personne qui a décidé pour une raison X ou Y que le module ne lui plaisait pas, et de l'autre une personne qui n'etant plus sous NDA decide de quand même garder les sources fermées pour un motif noble ou non.
Ce qui m'embete le plus c'est que j'ai déjà vu ce type de comportement... Chez XFree86.
Kha
[^] # Re: fnac et emi mis en examen
Posté par Jerome Herman . En réponse au journal fnac et emi en examen a cause des protections sur les cd audio. Évalué à 3.
Il faut insister un peu.
Si ils invoquent le piratage comme motif, dire que vous voulez le même CD et que donc leur argument ne tient pas. Là ils peuvent difficilement refuser.
Quand vous ramenez un CD pour la troisième fois en faisant un vrai scandale a chaque fois, et que tout le monde dans le magasin y compris le manager sait qui vous êtes ils reprennent les CD. Et vite encore.
Kha
[^] # Re: Il manque...
Posté par Jerome Herman . En réponse au message Système de message personnel. Évalué à 3.
je dirais que ce qui manque le plus c'est la possibilité de citer un commentaire dans un message que l'on envoit au posteur dudit commentaire. Ca permettrait de déporter les discussion techniques/les trolls un peu trop violent/les inimitiés naissantes ailleurs que dans les commentaires d'une news.
Enfin bon c'est juste une idée en passant.
Kha
[^] # Re: Euh...
Posté par Jerome Herman . En réponse au journal Firefox c'est mort pour moi..... Évalué à 3.
Reste à voir la config dans le script de config automatique auquel IE ne doit pas manquer de se referer. Mais si les admins sont bons il y a peu de chance...
Kha
[^] # Re: C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
Non, mon argument est que compte tenu du fait que les pilotes emulent un grand nombre de fonctions, il est beaucoup plus simple de comprendre ce que font les différents appels matériels.
Ce n'est donc pas avec que l'on va voler la technologie du fabricant.
Comme les APIs sont émulés en utilisant de facon simpliste des fonctions plus évoluées, ca aide au contraire beaucoup a comprendre l'ensemble du pipeline et sa compisition.
Il me paraît évident qu'une équipe avec des connaissances à jour, spécialisée en cartes graphiques, et focalisée sur ce sujet précis peut faire de même et obtenir très vite de très bons résultats.
Le gros problème des cartes graphiques est qu'elles sont faites pour fonctionner en DSP, soit donc efectuer plusieurs opérations simultanément (bon en fait souvent plusieurs fois la même opération, bien que les shaders ait pas mal changé la donne a ce niveau). Toute personne qui ayant le code source s'est amusé a faire un débuggage d'un programme qu'il connaissait et dont il avait le source sait a quel point le multithreading peut être usant. Suivre le déroulement d'un programme sur plus de 4 threads en simultané demande des capacités zen et un nivau de concentration assez énorme.
Une fois que l'on sait ca, il est assez facile de se rendre compte que surveiller 16 pipelines de 8 instructions doubles en DSP (donc 256 opérations simultanées sur la puce) d'après des bribes de pilotes et un affichage a l'écran c'est assez violent a faire quand même. Si on ajoute à celà que l'instruction "simple" de lookup texture peut être utilisé soit pour connaitre la valeur d'un pixel de facon a afficher la texture, soit pour servir de map d'éclairage, soit pour initialiser des shaders on comprend que ca fait beaucoup de tests et de spéculations pour pas grand chose niveau résultat.
Il est tout-à-fait possible pour un fondeur de puces de procéder à la rétro-ingéniérie physique d'un circuit déjà intégré !
J'ai joué a celà sur des puces 8 bits aussi. Mais une fois de plus on parle ici de puces de plus de 50 millions de transistor, gravées au plus fin, réparties sur 8 a 16 couches en recto verso. Il faut donc les ouvrir sans rein casser, les éplucher feuille a feuille (toujours sans rien casser) et ensuite les transmettre a une photographe spécialiste dans uen salle blanche d'indice monstrueux pour qu'il fasse l'inverse de ce qui marche déjà moyennement(yields de 10% pour les processeurs "simples") a savoir faire un cliché grand taille des lamelles qu'on lui donne. Rein que cette dernière étape, au prix de l'heure de mobilisation de salle blanche risque d'être très couteux très vite.
Ces arguments sont valables pour des secteurs de pointes comme les cartes graphiques par exemple, pas pour d'autres périphériques telles que les imprimantes, souris, etc.
Je dirais même plus, ces arguments ne sont valables que pour les périphériques ne pouvant physiquement pas bénificier d'une interface unifiée pour les accès et les appels matériels. C'est a dire a peu de chose près : les cartes graphiques et les carte sd'aquisition multistandards haut de gamme. Même une carte son très haut de gamme qui fournit 4 interface type wave et une interface midi en accès matériel n'a pas vraiment besoin de jouer les chochottes par rapport au contenu de son driver de toute facon c'est une norme ! On a juste besoin de connaitre l'adresse et éventuellement l'interruption a appeler pour que ca marche. Le code est souvent déjà écrit.
Cela se faisait avant !
Tout a fait. J'ai encore le schéma de montage complet de la vieille télé de mes parents. Mais pour être exact tout le monde le faisait avant, aujourd'hui plus personne ne le fait. Il s'agirait donc de convaincre TOUS les intervenants du monde des cartes graphiques de relacher les sources de leurs pilotes le même jour a la même heure pour qu'ils acceptent. Bien entendu il faudrait aussi qu'il y ait un moyen de vérifier que les sources relachées sont complètes, a jour et compilent. Ca va être dur...
Kha
# Il a perdu un avantage...
Posté par Jerome Herman . En réponse au journal muvo2 ou non. Évalué à 3.
Malheureusement la nouvelel version ne permet plus d'extraire le disque facilement.
En tout cas pour ce qui est de là compatibilité Linux pas de problème, mais en ce qui concerne la compatibilité avec des oreilles humaines standards elle est jugée faible, voire insuffisante.
Te voilà informé.
Kha
[^] # Re: C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 3.
C'est très sérieux si tu parles de la mise a jour d'OpenGL. Ati compte bien raffler les perfs OpenGL a ses concurents (ici c'est Wildcats qui est visé) sur les applications pros. Si au passage ils peuvent ramener les perfs de la X800 au niveau de celles de la 6800 sous Doom3 je suis sur qu'ils ne se priveront pas.
Si tu parles de drivers Fire GL sous Linux. Il s existent déjà pour 90% des cartes et 100% des cartes sorties par ATI (ie créées après le rachat de Fire GL)
Il y a quand meme des outils qui permettent d'installer les drivers sur des radeons mobiles
Oui mais ca part du principe que le design utilisé par le constructeur est proche de celui de référence fourni par ATI. Et ben des fois il y a des surprises, surtout dans les cas ou sur les puces IGP la mémoire de la CG est en fait celle de l'ordi.
En plus c'ets un peu du bricolage...
Kha
[^] # Re: No pasaran !
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 0.
La question est plus à mon sens de savoir quand raler. ATI n'est certes pas le meilleur contributeur à la démocratisation de Linux (et loin s'en faut), mais ils ont tout de même l'air bien décidé a faire quelquechose. Il sont parit en phase de réécriture des drivers avec réimplémentation complète de l'OpenGL pour bien sur de meilleures performances sous windows, mais aussi pour une plus grande facilité de mise a jour et d'écriture des drivers sous Linux. Et si on les laissait finir pour voir ce que ca donne avant de demander plus ?
On pourrait au moins attendre que la nouvelle génération de drivers OpenGL soit sortie sous Windows avant de hurler "Et Linux Alors ?"
Ou alors on pourrait attendre qu'il y ait au moins deux jeux qui justifient la création de tels drivers, parceque les gens qui hurlent disent tous la même chose sur les forums. On n'entend pas de "tel jeux est injouable/trop lent/trop lourd sous Linux" mais des je fais seulement xxxx fps sous GLXGears. Et ça, ça a le don de m'ennerver un peu.
Enfin bon c'est mon opinion a moi....
Kha
[^] # Re: C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
Si tu veux avoir une excellente vu d'ensemble de l'interieur des puces de CG il te suffit d'aller trainer du coté de HardwareFR.
Tu m'excuseras je coupe le reste parceque ta comparaison n'est pas valable.
On est passé d'un modèle statique (cracheur de poygone + textures avec lissage) a un modèle dynamique. La première génération s'apellait T&L (Transform and Lightning) Grosso modo les cartes ne faisaient plus seulement du rendu "brutal" mais devenait capable d'effectuer des opérations complexes sur les polygones (placement, rotation, éclairage) déchargeant ainsi le CPU d'autant.
On est aujourd'hui passé a un mode de shaders, des suites de micro instructions effectués soit sur un ensemble de vertex (une ligne d'un polygone) soit sur les pixels d'une texture. Pour des raisons de "place" dans le GPU Il n'était pas question d'empiler les transistors pour avoir d'un coté une archi statique, de l'autre une archi T&L et enfin une suite d'archis supportants les shaders de différentes versions pour Directx et OpenGL.
La bonne approche consiste a faire le mieux possible les unités les plus évoluées en émulant les autres quitte éventuellement a rajouter un peu de logique dans le pro pour pallier quelques manques ou faiblesses des perfs par émulation.
En d'autres termes dans un pilotes de cartes graphiques moderne, il y a les Paths Shaders 2, les paths shaders 1.x , les paths T&L et les paths statiques, avec a chaque fois un max d'astuce de programmation pour optimiser l'émulation le plus possible. C'est çà ou faire exploser le nombre de transistor de la puce (et aujourd'hui même SGI fait comme ca sur les CGs des workstation...)
Contrairement a une archi CPU classique on a pas une interface de programmation normalisé et de niveau relativement élevé (si tant est que l'on puisse parler de haut niveau pour de l'assembleur par opposition au byte code) , mais on a une foule d'interfaces qui passent par des chemins différents et qui sont aussi proche du GPU core que possible. Dans un cas on a le manuel utilisateur dans l'autre des plans détaillés pris sous plusieurs angles différents, détaillant composant par composant le chemin pris par telle ou telle instruction haut niveau (au sens appels OpenGL/DirectX cette fois).
Du fait de la versatilité des applications graphiques et des besoins très différents que peuvent avoir les différents intégreurs/éditeurs les fabriquants de cartes graphiques ne peuvent pas "fermer" leur carte dérrière une interface unique comme c'est souvent le cas pour les autres cartes ou processeurs. D'ou leurs craintes de voir les sources de leurs drivers entre les mains d'un concurrent.
Kha
# C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
1) Il sont déjà en train de réécrire le support OPenGL complet de leur puces modernes de facon a pouvoir fournir une acceleration de meilleure facture sous windows d'une part et surtout sous Linux ou leur produit haut de gamme (FireGL) commencent à avoir du mal a suivre autre chose que les applications leaders (Maya par exemple)
2) Pour les puces inférieur a la 8500 ils ont toujours dit qu'ils fourniraient une partie des specs mais qu'ils ne feraient jamais de drivers Linux.
3) Toutes les Puces X800 et dérivées stand-alone ont des drivers en cours de dev sous Linux (voir déjà opérationnels pour les FireGL)
4) Ce ne sont pas eux qui font les cartes sur lesquels sont installés les puces radeon mobiles, ils fournissent juste un desgin board et un kit de dev drivers. Il ne fournissent d'ailleurs pas non plus les drivers windows pour chipset mobile.
5) En ce moment ils vendent par centaines de milliers les X800s aux OEM (Dell et Sony notamment a qui NVidia sort par les yeux.) Alors que Nvidia a les pires yields qui soient sur la 6800 extreme (quelques centaines d'unités produites). Donc que l'ensemble de la communeauté se mobilise pour ne plus acheter leur produit ils s'en moquent un poil en ce moment.
6) Les gens qui ont vraiment besoin des capacités 3D ont accès aux drivers FireGL pour n'importe quelle cartes, même si il faut parfois utilise run serveur X propriètaire, de toute façon les applications comme Maya ou les applis de CAD professionelle utilisent des drivers propriétaires optimisés souvent dévellopés par le vendeur de la station de travail en collaboration avec l'éditeur du programme.
7) ATI est en train de gagner la guerre des cartes graphiques pour Power User/Gamers fou. Libérer les drivers maintenant ne leur viendrait même pas a l'idée (Un pilote n'est pas seulement un programme informatique stand alone, en l'analysant on peut souvent en apprendre beaucoup sur les choix technologiques et l'architecture du concurrent).
Bref tout ca pour dire que je ne signerais pas la pétition et que je continuerais a acheter du matériel ATI encore un moment (Même si je reconnais beaucop de qualités à la 6800, il y a encore trop de choses bloquantes pour que je me tourne sérieusement vers cette carte.)
Kha
[^] # Re: Vu comme ça ...
Posté par Jerome Herman . En réponse au journal Le paradis européen. Évalué à 8.
Pour plagier Guitry : "L'Europe c'est résoudre a 25 des problèmes qu'on aurait jamais eu tout seul."
Kha
[^] # Re: Pitié !
Posté par Jerome Herman . En réponse à la dépêche Pique nique du libre en août 2004 à Paris. Évalué à 3.
Rendez-vous de 12H00 à 12h15 sur l'un des pieds de la Tour Eiffel comme indiqué à le plan
Mouais bof. Pas convaincu...
Kha
[^] # Re: Hum tu peux préciser ?
Posté par Jerome Herman . En réponse au journal Mandrake Cooker - la curiosité est un vilain défaut. Évalué à 4.
Hmmm.. Avec ca plus les symptomes evoqués dans ton journal, ca sent a plein nez le DHCP qui galère.
Essaye de mettre une adresse fixe sur ta carte et de faire un dhcpcd une fois que tu as booté et que tu t'es logué.
Kha
[^] # Re: MD5, un algo de cryptage ?
Posté par Jerome Herman . En réponse au journal Deux Cryptage cassé ???. Évalué à 1.
MD5 et SHA-1 ne sont pas facilement decryptables, Ce sont des hashs dont le but dans la transmission de données est d'assurer l'authenticité d'un fichier (eventuellement en clair). Pour chiffrer les données et faire des sigantures autant se rabattre sur des systèmes à clefs publiques beaucoup plus adaptés a ce genre de choses.
La double empreinte est peut être un afaiblissement de la sécurité au final.
En terme de sécurité, surtout si le message est déjà en clair (par exempel les RPMs de chez Mandrake) pas vraiment non.
Kha
[^] # Re: On reste sobre et on respire.
Posté par Jerome Herman . En réponse au journal Deux Cryptage cassé ???. Évalué à 8.
C'est vrai j'ai l'air ? Chouette je vais pouvoir monter d'un cran mon pipomêtre.
Non sans rire, il s'agit là d'accadémiciens de très haut niveau qui ont découvert une faille en 1998 et une deuxième en 2004 dans un protocole considéré comme obsolète par ses inventeurs depuis 1994, je suis absolument pas au niveau de commenter leur recherche ou d'extrapoler sur les effets de bords.
En ce qui concerne les autres SHA, pour l'instant rien n'a été trouvé. Mais la première faille (celle du bit neutre trouvée en 1998) voit ses chances de se produire réduire au fur et a mesure que la force augmente. En plus les algos SHA-256 et plsu ont été modifiés par rapport a SHA-1 lequel était déjà une correction de SHA-0 (Le RSA savait par preuve mathématiques qu'il y avait une faille dans SHA0, mais ils ne savaient pas ou et quoi). Ceci étant je n'ai pas entendu parler de la moindre alerte concernant les SHA > 0, mais il y a des rumeurs sur SHA1. Si elles sont fondées alors le problème pourrait bien remonté sur les autres SHA...
SHA0 était une variante de MD4, il est donc possible que les failles de SHA0 soient venus de MD4 et que celles-ci soient aussi remontés dans MD5 de façon plus ou moins abbatardie par les modifs de l'évolution MD4->MD5.
Voilà a peu près totu ce que je sais.
Kha
[^] # Re: une question pour l'inculte que je suis :
Posté par Jerome Herman . En réponse au journal Deux Cryptage cassé ???. Évalué à 3.
Bon déjà ca n'est aps vraiment un signature, c'est un hash.
Et ensuite la taille pour la certifier, il va bien falloir a un moment ou a un autre la hasher ou la signer non ?
Kha
[^] # Re: MD5, un algo de cryptage ?
Posté par Jerome Herman . En réponse au journal Deux Cryptage cassé ???. Évalué à 10.
Là on peut dire 0. Pour être exact il y a une chance sur 2^64 soit environ une chance sur 16 000 000 000 000 000 000. (16 milliards de millards). C'est plutôt faible non ?
Par contre réussir a génrer un "faux fichier" possédant a la fois le même MD5 et le même SHA-1 qu'un autre doit être monstrueux. Et le faux fichier doit avoir au final une taille assez importante, probablement plusieurs To.
Donc si vous voyez un fichier avec le bon SHA-1 et le bon MD5 mais qui fait plus de 4 Terra Octets de données, ne le téléchargez pas ! Si ca se trouve il a été spoofé !
Kha
# On reste sobre et on respire.
Posté par Jerome Herman . En réponse au journal Deux Cryptage cassé ???. Évalué à 10.
Pour l'instant un super calculateur Bull a reussit en 80 000 heures de calculs CPU a générer deux fichiers qui on le même SHA0. L'algorithme est de complexité 2^51.
On est encore très loin du moment ou on va pouvoir remplacer un fichier existant par un autre avec un trojan en rajouter des données "poubelle" a la fin du fichier pour obtenir le même md5.
Bref remplacer le fichier ftp.rpm par un virus en gardant le même MD5 c'est pas pour tout de suite.
Il y a définitevement une faille, des gens plus ou moins bien intentionnés vont probablement s'en servir un jour, mais pas avant plusieurs années.
Vous pouvez continuer a utiliser SHA0 un petit moment, et ceux d'entre vous qui paniquent peuvent soit faire un couple SHA0( ou 1)/MD5 soit faire du MD5+Signature du binaire.
Ceux qui ont pris l'habitude de signer des hashs pour une double sécurité, devraient commencer a songer sérieusement a signer les binaires ou a signer des couples de hashs.
En bref, dormez en paix braves gens.
Kha
[^] # Re: Pont
Posté par Jerome Herman . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 4.
En fait la XLib n'ets pas capable de gerer plusieurs instances de certains paramètres. Par exemple les propriétés d'une fenêtre ne peutvent exister qu'en un seul exemplaire, XGetWindowsProperties va donc entrainner un blocage de toutes les requètes qui ont besoin des propriétés d'une fenêtre ou des fenêtres racines. Celà implique que si on fait une requête sur la fenêtre racine, plus aucune requête de propriété sur les fenêtres ne peut avoir lieu. L'ensemble des applications est bel est bien bloqué jusqu'à ce que la XLib est finit de parser les propriétés et d'agir en conséquence.
Par contre la mauvaise nouvelle est que sous XCB une grosse partie de la synchro et de la gestion des threads est encore faite a la main. Les cookies doivent être allouées et traités par le dev lui même.
Plus ou moins. En fait, utiliser XCL permet de remplacer XLib par la meme interface (les signatures de fonctions sont identiques).
En fait XCL n'existe plus vraiment, il s'agit désormais d'une version modifiée de la XLib pour laquelle XCB fait un peu effet de proxy. Il est ainsi possible de passer outre les problèmes vu plus haut.
Kha
[^] # Re: et obtenir une license ?
Posté par Jerome Herman . En réponse au journal Le droit d'écrire. Évalué à 2.
Kha
# Attention !
Posté par Jerome Herman . En réponse au journal Technologie No eXecute. Évalué à 10.
- Le NX Bit : la technologie qui permet de donner les droits en execution a un segment mémoire, en d'autres termes on définit une zone mémoire comm étant non executable (data only) et il devient impossible de demander au CPU d'executer quelques intructions que ce soit dans cette zone. Cette technologie n'existe pas sur architecture x86.
- La protection de pile : Qui interdit au gestionnaire de mémoire et a l'OS de jumper la pile en execution. En d'autres termes il devient impossible de placer des instructions au sommet de la pile et d'attendre que le programme l'execute.
C'est la deuxième technologie qui pose problème sur les logiciels mal codés. En effet certains prog n'hésite pas a accumuler le code sur la pile et à l'executer après. Bien entendu cette façon de faire entrainne une faille de sécurité dans 90% des cas.
Kha
[^] # Re: Pont
Posté par Jerome Herman . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 3.
Le problème étant que les fonctions qui font appel aux propriétés de la fenêtre racine (profondeur de couleur, renvoit de segments bitmaps pour fausse transparence, positionnement automatique de la fenêtre au pixel de valeur absolue le quart de l'écran etc.) bloquent l'ensemble de la XLib qui va refuser toutes les autres demandes. Le serveur lui pendant ce temps là va se tourner les pouces.
Comme les effets nécessitant des appels bloquant ssont de plus en plsu nombreux (bords de fenêtres arrondis, fond transparent ou translucide, lissage de polices, positionnement automatiques de fenêtres etc.) On imagine bien l'impact que celà finit par avoir.
La plupart des applis essayent de mettr eun maximum d'information en cache pour éviter d'avoir a refaire un lookup gourmand, mais là c'est la mémoire qui prend et il y a aussi un ralentissement des perfs...
Kha
[^] # Re: Pourquoi un remplacement ?
Posté par Jerome Herman . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 8.
Les equivalents XLib des solutions propriétaires sont assynchrones. En ce qui concerne la XLib de XFree, je parlerais bien de l'attitude et des réponses faites par le projet XFree a mes demandes et à d'autres pour le passage de la XLib en mode assynchrone, mais on va encore me traiter de trolleur.
Kha
[^] # Re: Pont
Posté par Jerome Herman . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 5.
sans être vraiment avantagées au niveau vitesse, les applications XLib utilisant le pont auront au moins la gentilesse de ne pas bloquer les autres. En d'autres termes utiliser le pont plutot que la librairie native permettra de garder le serveur X disponible pour faire autre chose, même quand une requête XLib sera en cours d'execution.
Kha