L'équipe de développement annonce que ce n'est qu'un premier jet, qu'il y a encore des améliorations et sûrement des corrections à apporter, mais souhaite faire part de leur bonne foi par l'intermédiaire de cette disposition. Ils espèrent en outre pouvoir travailler avec la communauté X.org ainsi que MESA.
On pourra également retenir qu'Intel prend donc une décision opposée à celle de ses concurrents au moment même où nous avons appris le rachat d'ATI par AMD.
Merci également à Andreï V. Fomitchev qui nous a signalé l'information suivante :
Dans une interview à InfoWorld, Hal Speed, un manager d'AMD, indique (dans le dernier paragraphe) que l'open-source peut représenter une part importante des pilotes ATI et qu'il est temps que les fonctionnalités graphiques évoluent...
Aller plus loin
- Annonce de la mise à disposition de pilotes libres (3 clics)
- Article sur Slashdot (2 clics)
- Annonce du rachat d'ATI par AMD sur LinuxFR (journal) (1 clic)
- IntelLinuxGraphics.org (9 clics)
- Licences (1 clic)
- Téléchargements (2 clics)
# Les bonnes habitudes perdurent...
Posté par ragoutoutou . Évalué à 10.
Enfin, vu l'historique d'Intel à ce niveau, on peut dire que l'on est en présence d'une véritable politique favorable au logiciel libre, et non en face d'une manoeuvre destinée à se faire un coup de pub...
De son côté, AMD semblerait décidé à joindre l'acte à la parole concernant ses bonnes intentions envers le logiciel libre et semblerait considérer l'ouverture de pilotes pour les cartes ATI...
http://www.infoworld.com/article/06/08/02/32OPcurve_1.html
Pourvu que cela se confirme.
[^] # Re: Les bonnes habitudes perdurent...
Posté par espace . Évalué à 10.
[^] # Re: Les bonnes habitudes perdurent...
Posté par mansuetus (site web personnel) . Évalué à 8.
En cherchant un peu sur google et dans le portable d'une amie (si je dis ma copine, définitivement, on va me moisser ;p ), j'ai vu qu'il existait des cartes video internes, comme le dit clairement ton post, d'ailleurs.
mais Intel fait-il des cartes graphiques AGP ?
google, normalement mon pote, ne m'aide pas trop... Il parle plus des supports AGP sur les cartes mères que de cartes graphiques !
Et mon site de comparatif de prix en ligne préféré ne parle pas d'intel en cartes graphiques...
En fait, j'aimerais soutenir les entreprises qui font du pro linux, et je veux changer de carte video, pour faire du triple-écran (sur une seule carte AGP...) ça me semble être une occasion en or pour prouver à mon échelle que ces idées sont non seulement sociales mais en plus, lucratives !
Bref, comment savoir quelles cartes graphiques ont ce chipset ?
[^] # Re: Les bonnes habitudes perdurent...
Posté par yannig (site web personnel) . Évalué à 4.
[^] # Re: Les bonnes habitudes perdurent...
Posté par Francois B . Évalué à 5.
Les seules cartes concurentes à l'époque étaient la série des G200 de Matrox et la 3DFX 2. Nvidia allait seulement pointer le bout de son nez quelque temps plus tard avec son Riva 128 (qui avait quelques problèmes de rendu en 3D, mais qui était néanmoins une petite révolution à l'époque) et ATI était, on va dire, un peu à la traîne ;-)
[^] # Re: Les bonnes habitudes perdurent...
Posté par Aldoo . Évalué à 6.
Or l'Intel 740 doit dater plus ou moins de ces eaux là, en tout cas pas longtemps avant, et en tout cas après la Voodoo 1 (1996), voire la 2 (1998), mais je ne suis pas sûr.
Je me rappelle que l'i740 était entre la Voodoo 1 et la Voodoo 2 en terme de performances, quoique son rendu laissait à désirer... peut-être la faute à des drivers mal finis. En tout cas j'ai dû supporter le coup des textures clignotantes sous Halflife 1, grrr !
ATI effectivement était un peu à la bourre niveau 3D à cette époque et se positionnait plutôt en concurrent de Matrox avec les cartes multifonction à la All In Wonder.
[^] # Re: Les bonnes habitudes perdurent...
Posté par Mark Havel . Évalué à 3.
# OpenGraphics ?
Posté par Ontologia (site web personnel) . Évalué à 10.
http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics
Avec une tel nouvelle, le marché des libristes susceptibles d'acheter une carte pour son côté OpenSource risque de se réduire alors qu'il n'était déjà pas énorme...
Cela va t-il provoquer la mort e ce (beau) projet ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OpenGraphics ?
Posté par arnaudus . Évalué à 10.
Je crois que c'est ce qu'on appelle un dégat collatéral... La mort de ce projet signifierait qu'on n'aurait plus besoin d'eux! Ça serait magnifique, non?
[^] # Re: OpenGraphics ?
Posté par ragoutoutou . Évalué à 10.
ça n'impactera sans doutes pas ou peu son développement, la philosophie de ce projet étant tout de même son principal pillier.
Les pilotes précédents d'Intel étaient déjà libres... Si OpenGraphics a été capable de survivre aux versions précédentes, il survivra aux suivantes...
En outre, d'ici à la commercialisation des cartes OpenGraphics (qui en sont encore au PCI), il va y avoir encore de l'eau qui coulera sous les ponts, tout le monde n'a pas envie d'attendre. Quand opengraphics sortira son produit, il sera toujours temps de peser le pour et le contre et de voir si il présente une bonne combinaison d'avantages techniques et philosophiques sur ses concurrent Intel (et AMD si celui-ci tient ses promesses)
[^] # Re: OpenGraphics ?
Posté par GigaHertz . Évalué à 4.
Maintenant, concernant l'annonce actuel, ça sent vraiment la "contre attaque" face à AMD, cela intervient tout juste après le rachat, grosse coïncidence.
Evidemment, rien ne dit qu'AMD-ATI™ ouvrirait ses puces Rx00, mais je pense sans dire de bétise que ça aurait-été la suite logique.
Nous voilà libérés d'un poid, ça va enfin décollé - Xorg/XGL, les jeux, logiciel 3D et ce pour tous les unix libres!.
bye
[^] # Re: OpenGraphics ?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
Mais les jeux? Je crois pas non... La dedans y'a rien qui va faire changer quoi que ce soit sur les jeux.
[^] # Re: OpenGraphics ?
Posté par dinomasque . Évalué à 10.
Je me plait à imaginer qu'AMD-ATI a fait cette annonce pour ne pas avoir l'air à la traine par rapport à Intel.
En tout cas, comme tu le dit, c'est surtout une très bonne nouvelle puisqu'il n'est plus nécessaire pour avoir une accélération OpenGL "moderne" de subir les désagréments d'un driver propriétaire : instabilité, mauvaise intégration, retard, incompatibilité avec une informatique de confiance (qui sait quels bridages et autres cochonneries sont dans les opaques drivers binaires ?), etc.
BeOS le faisait il y a 20 ans !
[^] # Re: OpenGraphics ?
Posté par spaceparanoids . Évalué à -1.
Mon point de vue est que tant que DirectX aura un train d'avance comme aujourd'hui, les éditeurs n'iront pas chercher ailleurs. Si OpenGL (ou autre framework libre type SDL) arrive à combler son retard avec une API C++ plus légère et multi-plateforme, avec les features des nouvelles cartes implémentées en tant et en heure, ça risque de n'être plus pareil. Les éditeurs commenceront je l'espère à réfléchir et à offrir une alternative qui leur soit pas trop chère à développer.
[^] # Re: OpenGraphics ?
Posté par farib . Évalué à 10.
Puis bon, l'avance de DirectX, on la cherche dans les graphismes de Doom3.
Enfin, je l'ai déja dit, ça empeche pas de développer des jeux multiplateforme PC console, simultanément, avec eventuellement portage sur PC ou console décalé, et ça marche toujours.
[^] # Re: OpenGraphics ?
Posté par GigaHertz . Évalué à 3.
Non, ce que je voulais dire par le décollage avec des pilotes libres fonctionnels, c'est qu'on aura maintenant un intérêt à créer des jeux LIBRES, c'est peut-etre pas la pensée de tout l'monde, mais au moins la mienne et de quelques amis.
Si c'est pour créer un jeu libre 3D qui ne fonctionne qu'avec de l'ati proprio ou du nvidia, j'vois pas trop l'intérêt. J'ai abandonné 3 projets pour ça.
Si je crée un jeu libre en 3D, c'est que pour tout le monde y ait accès et promouvoir le LIBRE.
Néanmoins, je pourrais renouer les liens avec mon envie grâce à OpenGraphics.
bye
[^] # Re: OpenGraphics ?
Posté par pasBill pasGates . Évalué à 1.
C'est loin d'etre que marketing, le gros probleme des editeurs de jeux c'est que les couts de developpement des jeux explosent. Leur donner un environnement de developpement et des APIs qui accelerent et rendent le developpement plus simple leur sauve de l'argent, c'est de plus en plus important pour eux.
Puis bon, l'avance de DirectX, on la cherche dans les graphismes de Doom3.
Ben... http://www.next-gen.biz/index.php?option=com_content&tas(...)
"The Xbox 360 will probably will be id's primary development platform. As it is right now, we would get the game up on the 360. When I would do major hack-and-slash architectural changes it was back on the PC, but it’s looking like the Xbox 360 will be our target. All of our tools are on the PC, and we’re maintaining the game running on the PC, but probably all of our gameplay development and testing will be done on the Xbox 360. It’s a really sweet development system."
[^] # Re: OpenGraphics ?
Posté par Croconux . Évalué à 6.
Ca ne changera rien au problème. Les jeux suivent la même tendance que le cinéma : L'explosion des budgets, une débauche d'effets spéciaux, etc. Les effets spéciaux au cinéma ont fait d'énormes progrès. On peut faire aujourd'hui sur un simple PC ce qui réclamait une batterie de stations Silicon Graphics il y a quelque années. Est-ce qu'on a vu les budgets des films baisser ? Non, au contraire. Tous les studios, grands et petits, ont bénéficié de ces améliorations. Il y aura toujours le même fossé entre les gros et les petits. Ces derniers étant voué à mourir écrasés par les poids lourds du "divertissement" qui sortent des "produits" calibrés pour cartoner sur un public bien ciblé. Comme la musique et le cinéma, les jeux vidéo suivent la même voie. Il y a peu de jeux inventifs. La plupart reprennent des ingrédients bien connus et font la même chose qu'avent en plus beau.
[^] # Re: OpenGraphics ?
Posté par pasBill pasGates . Évalué à 2.
Ces societes sont notamment connues pour regulierement virer la moitie de l'equipe a chaque fin de cycle, pour reengager quand ils recommencent a avoir besoin de monde, bref, elles font tout pour reduire leurs couts.
[^] # Re: OpenGraphics ?
Posté par reno . Évalué à 9.
Oui enfin peut-être: les cartes Intel ne sont que dans les portables et pour AMD-ATI ce n'est pas encore fait..
Mais c'est sur que si ca arrive, cela libérerait Xorg/XGL, mais pour les jeux, ils ne faut pas réver.
Par exemple la majorité des jeux actuels sont fait en Direct3D alors qu'utiliser OpenGL simplifierait beaucoup le portage vers d'autres OS, cela montre bien que les producteurs de jeux n'en ont rien à faire de porter les jeux vers d'autres OS , tout simplement parce que ce n'est pas rentable.
[^] # Re: OpenGraphics ?
Posté par gaolinn . Évalué à -1.
Dur chemin de croix que celui de passer pour des gens qui ne veulent pas payer les logiciels qu'ils utilisent. Qui plus est, fervents détracteurs des sécurités qui protégent leurs produit des pirates, que vous êtes tous ;o)
Alors non, il sont pas prêt de débarquer sous Linux.
[^] # Re: OpenGraphics ?
Posté par Ontologia (site web personnel) . Évalué à 4.
La question de la compatibilité binaire doit surement refroidir les rares véléités de proposer un jeu sous Linux.
Chose surement posssible, lorsqu'on sait que le moteur de quake est développé sous Linux (à moins que ça ait changé depuis).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: OpenGraphics ?
Posté par ragoutoutou . Évalué à 5.
Les jeux et certaines applications pro constituent les dernières raisons pour lesquelles j'ai encore un pc avec windows à la maison (j'ai aussi des pc's avec linux, rassurez-vous).
[^] # Re: OpenGraphics ?
Posté par clearstream . Évalué à 8.
Je m'incris totalement en faux.
Les "problèmes" de compatibilité binaire dans Linux sont uniquement pour les drivers. Linus (et d'autres) ont été très claires sur ce point, il n'y a pas de compatibilité binaire même entre versions mineurs, point final. Il en est de même pour xorg.
Celà pour trois raisons :
1- ça ne regarde que le fonctionnement interne du noyau (respectivement Xorg).
2- c'est stupide
3- c'est un travail pénible qui rebutent les développeurs du libre
Par contre, pour tout ce qui est ABI coté programme utilisation Linux est quasiment parfait et offre toutes les fonctionnalités nécessaires :
- différentes versions d'API pour une seule librairie.
- possibilité à un programme de définir la version d'API dont il a besoin.
- support complet par les gestionnaires de paquet (en tout cas rpm).
- possiblité pour chaque programme d'utiliser ses propres librairies et non celle du livrée par le système (codé avec ld et -rpath ou avec LD_LIBRARY_PATH). Voire aussi de linker statiquement.
Enfin, il y a les sources des librairies ! Libre à qui veut de maintenir une version spécifique.
On peut voir que Gtk/Gnome se débrouille très depuis Gnome 2.0.
Faire tourner un vieux programme sous Linux ne pose pas de problème majeur. C'est souvent plus dure de le recompiler.
[^] # Re: OpenGraphics ?
Posté par Colin Pitrat (site web personnel) . Évalué à 6.
[^] # Re: OpenGraphics ?
Posté par pierthi . Évalué à 2.
Hum, hum, certains ont une vision nettement moins idylique de ce problème sous Linux. Notamment le développeur d'autopackage qui s'est cassé les dents sur quelques uns d'entre eux ...
http://plan99.net/autopackage/Linux_Problems
Mais bon, la compatibilitè binaire reste un problème "aisément" contournable. On peut toujours y aller bourrin : tout compiler en statique, ou alors mettre toute les bonnes versions de dll dans le répertoire de l'application.
[^] # Re: OpenGraphics ?
Posté par Vador Dark (site web personnel) . Évalué à 1.
Compiler en statique, ça va, je comprends. Mais... dll? Dans le répertoire de l'application? A mon avis, tu t'es planté de forum ;).
Sinon, il est parfaitement possible d'avoir plusieurs versions d'une lib en parallèle. Suffit de ne pas leur donner le même nom(inclure un numéro de version d'ABI dans le titre par exemple), où de les placer dans différents dossiers. Pas la peine de se faire des boxons pas possibles à tout coller dans le même dossier.
[^] # Re: OpenGraphics ?
Posté par Pierre Carrier . Évalué à 5.
DLL = Dynamically Linked Library, voir http://en.wikipedia.org/wiki/Library_(computer_science)
Repertoire de l'application : /usr/share/application/, voire un dossier dans lequel tout est place (/opt/application/, ensuite liens symboliques dans /usr/local/bin comme bon nombre de jeux commerciaux ou ce que je fais personnellement avec Eclipse)
[^] # Re: OpenGraphics ?
Posté par clearstream . Évalué à 2.
Et la concurrence ne fait pas mieux. Mais pour qui veut s'en donner la peine (n'oublions qu'on parle de logiciel libre !), par exemple les distributeurs ou les développeurs, ce n'est pas un gros problème.
[^] # Re: OpenGraphics ?
Posté par Mark Havel . Évalué à 0.
Mais à mon avis, le principal argument pour Windows s'appelle DirectX et Visual Studio plus que tout autre chose. Je ne connais pas d'API de ce style sous Linux. Même les jeux OpenGL utilisent DirectX pour le reste genre le réseau, les entrées sorties et le son. Tant qu'il n'y aura pas d'équivalent similaire sous Linux, on pourra toujours se brosser pour voir des jeux avec. Et je dirais même tant qu'il n'y aura pas d'équivalent similaire et multi plateforme de façon à ce que le portage se résume à une recompilation ou à un "build for: Windows & Linux".
[^] # Re: OpenGraphics ?
Posté par Frédéric-Emmanuel Picca . Évalué à 3.
[^] # Re: OpenGraphics ?
Posté par berti . Évalué à 1.
[^] # Re: OpenGraphics ?
Posté par Frédéric-Emmanuel Picca . Évalué à 2.
[^] # Re: OpenGraphics ?
Posté par berti . Évalué à 1.
Carte Nvidia GeForce FX Go5200 sous Ubuntu dapper.
[^] # Re: OpenGraphics ?
Posté par Frédéric-Emmanuel Picca . Évalué à 2.
[^] # Re: OpenGraphics ?
Posté par meh (site web personnel) . Évalué à 3.
# Dernières versions de gcc et g++
# Librairies et headers de SDL
# Librairies et headers de OpenGL
[...]
SDL doit être utilisé pour le fenêtrage et OpenGL pour l'affichage
# i965 ?
Posté par Nÿco (site web personnel) . Évalué à 6.
[^] # Re: i965 ?
Posté par Jux (site web personnel) . Évalué à 8.
Je n'ai pas l'impression que la carte soit déjà disponible, mais puisque le chipset i965 est fait pour les Core 2 Duo qui sont tous récent, on devrait bientôt voir des portables les proposant.
Par contre, plusieurs sites en parlent, avec comme seul info les specifications qu'on trouve dans la doc d'intel [1]
• Vertex Shader Model 3.0 (HW)
• Hardware Pixel Shader 3.0
• 32-bit and 16-bit Full Precision Floating Point Operations
• Up to 8 Multiple Render Targets (MRTs)
• Occlusion Query
• 128-bit Floating Point Texture Formats
• Bilinear, Trilinear, and Anisotropic MipMap Filtering
• Shadow Maps and Double Sided Stencils
Ces specs sont celles de la X3000, qui devrait être compatible DirectX10/Opengl1.5 d'après [2]
Ca a l'air assez prometteur en tout cas, reste à attendre des tests :-)
Il est tout à fait possible que je n'aie rien compris à la nomenclature intel et que ce commentaire soit complètement à côté de la plaque.
[1]http://www.intel.com/design/chipsets/datashts/313053.htm
[2]http://www.infododos.com/actu/view-news-1127078907.html
[^] # Re: i965 ?
Posté par cruciforme . Évalué à 5.
Si je me rappelle bien, il n'a pas atteint tous les objectifs qu'il s'était fixés.
Il n'est pas encore sorti mais c'est pour bientôt.
Il n'a pas vraiment de prix vu que c'est un northbridge pour carte mère avec partie graphique.
Je suis prêt à passer à une solution avec partie graphique intégrée pour ma part mais je crois que ça signifierait la perte du dual screen pour moi :/
[^] # Re: i965 ?
Posté par GigaHertz . Évalué à 1.
Pour Intel, j'en sais rien, mais pour ATI avec les pilotes libres actuels, il n'y a aucun soucis.
mais euh, on parle de portable ou de station fixe?
[^] # Re: i965 ?
Posté par clearstream . Évalué à 2.
Je crois qu'il y a des versions dual screen. A confirmer.
[^] # Re: i965 ?
Posté par cruciforme . Évalué à 2.
# Une part seulement ?
Posté par Arnaud . Évalué à 10.
[^] # Re: Une part seulement ?
Posté par GigaHertz . Évalué à 3.
[^] # Re: Une part seulement ?
Posté par Jean-Philippe (site web personnel) . Évalué à 2.
# Vous affolez ps, y'a anguille sous roche
Posté par iug . Évalué à 9.
Un pilote graphique était en deux parties, l'une pour le northbridge et l'autre pour le chip externe. Or, les développeurs X étaient déjà capables d'écrire des pilotes pour la partie northbridge, relativement bien documentée. Par contre, le cip externe variait d'une carte à l'autre, avec bien souvent un pilote en partie hardcodé dans le BIOS.
Au final, la qualité apparentes des drivers X variait d'une carte mère à l'autre, les fabricants intégrant des chips annexes différents sur leurs cartes mères.
# Mouaif
Posté par farib . Évalué à 2.
Ouais, enfin faut voir, ton argument est pas mal retournable. Intel fabrique pas des chips haut de gamme et n'a pas grand chose a cacher a Ati et Nvidia, donc ouvrir leur drivers, ca doit pas les gener plus que ca non plus...
[^] # Re: Mouaif
Posté par Joc M . Évalué à 2.
Perso, si AMD et NVidia faisaient de la pub comme ça, je serai plutôt d'accord.
[^] # Re: Mouaif
Posté par briaeros007 . Évalué à 2.
Pour le menrom / conroe , je suis pas si sur qu'il soit 200 fois mieux qu'un turion niveau économie d'énergie , à tester.
Quand à 'Intel c'est bon pour le libre', je rappellerais (chose que j'ai appris hier sur les commentaire avec TCPA toussa) que le dernier né de Intel , le conroe , utilise une technologie propriétaire de chez propriétaire appelé La Grande.
Et que niveau logiciel , on attend toujours les sources d'icc , du daemon proprio de certains cartes wifi, et de certains drivers wifi.
Bref c'est bien qu'ils fassent ça, mais ne nous emballons pas.
[^] # Re: Mouaif
Posté par TeXitoi (site web personnel) . Évalué à 1.
ouais, enfin, ca gène pas pour installer un linux. Le problème, c'est pas le chip, c'est son utilisation. Du moment que c'est désactivable ou qu'on peut l'utiliser sous nunux, je vois pas trop le problème.
Et que niveau logiciel , on attend toujours les sources d'icc , du daemon proprio de certains cartes wifi, et de certains drivers wifi.
tout les drivers wifi sont libres à ma connaissance. Ce qui fait chier, c'est qu'intel ne veut pas donner en libre distribution les firmwares, ça, c'est lourd. Pour le daemon wifi en root, c'est chiant, mais ils le changeront pas. Mais sous OpenBSD, cette carte marche très bien sans daemon proprio, dc y'a plus qu'a porter un vrai driver sous linux.
[^] # Re: Mouaif
Posté par briaeros007 . Évalué à 6.
le problème d'une arme a feu , c'est pas les munitions, c'est son utilisation.
/me sifflote
je te renvoie sur ce journal :
http://linuxfr.org/~patrick_g/21744.html
C'est bien plus qu'un simple firmware visiblement, et pour moi c'est pas ce que j'appelle "libre" (tout du moins pour linux)
alors peut être que depuis ça a changé, mais j'ai des doutes.
tout à fait, et pas grace à intel ! (j'aime beaucoup le 'yapuka' ;) )
Donc faut acceuillir l'annonce de la libération des drivers 3D comme une bonne chose, mais pas dire que intel essaie de tout faire pour le libre, c'est tout ;)
[^] # Re: Mouaif
Posté par ragoutoutou . Évalué à 4.
Pas tellement... ce que tu dis est vrai mais n'invalide pas mon argument... Offrir du matériel bas de gamme et créer une valeur ajoutée grâce à l'ouverture des pilotes est une stratégie qui se tient parfaitement.
# Futur antérieur..
Posté par Guillaume B. . Évalué à 3.
Dans tous les cas, bien que je me sois en partie trompé, je suis vraiment content de cette nouvelle, car c'est bien là un des dernier frein du libre pour une plus grande diffusion, et c'est un travail de titan qui est demandé aux développeurs que de recréer des pilotes libres en ingénierie inverse. Tout ce temps perdu, qui pourrait être passé sur autre chose dans le libre (ajout de nouvelles fonctions, optimisation, correction de bug), ou pour d'autres activités des contributeurs.
Vivement que tous les fabricants s'y mettent, ce qui va bien finir par se faire...
[^] # Re: Futur antérieur..
Posté par Guillaume B. . Évalué à 2.
[^] # Re: Futur antérieur..
Posté par sylware . Évalué à 3.
Pour un empilement "propre" des couches pour le support des cartes graphiques, il faudrait une couche de base que pourrait fournir DRI, mais indépendament de X. Cela permetterait l'implémentation d'un serveur X en DRI/OpenGL bien au dessus. C'est similaire à l'idée de Xegl. On peut pousser le vice plus loin: les toolkits modernes directement sur cet opengl indépendant de X (il faudra mettre au point des bibliothèques pour ce qui manquerait, par exemple, la gestion du curseur).
Je ne sais pas si c'est à DRI de gérer ça, mais il faut maintenant une interface bas niveau qui sache, sur une machine, gérer la présence de plusieurs cartes graphiques différentes avec plus ou moins de "heads", avec plusieurs utilisateurs les partageant. Cela semble être une des raisons qui a fait abandonné le développement d'Xegl par son auteur principal: faire Xegl maintenant, reviendrait à mettre la charue avant les b½ufs.
Donc, la libération des drivers, tant mieux, car tout le travail d'ingénierie inverse est évincé (ATI ne pas vendre la peau de l'ourse trop vite, et NVIDIA... hum...). Par contre, tout le travail à faire pour améliorer la couche élémentaire du support des cartes graphiques reste à faire.
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 3.
Pourquoi ?
La structure de Xorg a été significativement retravaillée ces dernières années.
[^] # Re: Futur antérieur..
Posté par oops (site web personnel) . Évalué à 3.
C'est DirectFBGL :
http://www.directfb.org/downloads/Core/README.DirectFBGL
[^] # Re: Futur antérieur..
Posté par un_brice (site web personnel) . Évalué à 0.
Donc pour moi, il faudrait refaire une autre API minimaliste conçue spécifiquement pour la 2d, et l'implémenter directement par dessus DRI (pour les perfs).
La transparence réseau serait un plus; surtout que ça permetrais de gérer proprement une confinement et faire que des applications de privilèges différents s'affichent sans risque sur le même écran (ce qui n'était pas le cas sous mswindows à l'époque où j'ai regardé).
Et on appellerais ça un serveur X.
De quoi tu parle ? De protéger les serveurs X les uns contre les autres ? M'est avis que ça seras dur vu que sous x86 on peine déjà à protéger le kernel contre la carte graphique, faute d'IO-MMU (peut être plus avec les nouveaux processeurs gérant la virtualisation, ou avec le hack de Linus avec le GART auquel j'ai rien capté).
[^] # Re: Futur antérieur..
Posté par Bruno Ethvignot (site web personnel) . Évalué à 5.
Déjà, tout le monde n'a pas un moteur de rendu OpenGL,
Depuis quelques années la totalité des cartes graphiques vendues, et sûrement ta propre carte graphique, gèrent la 3D. La plupart de ces cartes 3D dédient 90% de leur silicium au pipeline 3D. Tu as payé uniquement pour du matériel 3D alors ne serait-il pas bien si ton interface utilisateur l'utilisait ? Apple et Microsoft semblent déjà avoir reçu le message que la 3D est la voie à suivre et ont fait la transition.
et rien ne prouve qu'OpenGL dure éternellement. En plus, OpenGL a clairement pas été conçu dans cette optique.
Je ne vois pas ce qui pourrait tuer OpenGL ? OpenGL est une technologie qui a fait ses preuves, et qui est encore utilisé énormément aujourd'hui (sous Linux, MacOSX et PS3 par exemple). Depuis le 31 juillet OpenGL ARB a voté le transfert du contrôle de l'API OpenGL au groupe Khronos. Le groupe Khronos est composé de plus d'une centaine de sociétés comme Apple, Dell, Google, ARM, Philips, Sun, ATI, Nvidia, Intel, Nokia, Samsung, etc. Voir la page http://www.khronos.org/about/ pour la liste détaillée.
Donc pour moi, il faudrait refaire une autre API minimaliste conçue spécifiquement pour la 2D, et l'implémenter directement par dessus DRI (pour les perfs).
Pourquoi réinventer la poudre ? Pourquoi développer une nouvelle AP 2D alors que l'API OpenGL ES existe déjà (la 3D peut dessiner de la 2D) ? Jon Smirl, ancien développeur de Xegl, proposait d'utiliser directement OpenGL comme un pilote de périphérique afin de tracer la frontière au-dessus du jeu des fonctionnalités actuellement implémentées dans le silicium afin de permettre à la pièce de silicium d'évoluer sans perturber l'API. Le serveur graphique principal serait implémenté en utilisant des API multi-plates-formes comme les sockets, OpenGL et EGL.
Lire :
http://linux.tlk.fr/traitement-graphique/
[^] # Re: Futur antérieur..
Posté par un_brice (site web personnel) . Évalué à -1.
Plus sérieusement, tu confond l'API et les capacité sous jacentes du hardware que l'API exporte.
Pour ce que j'en sait, les widgets sont pas principalement dessinés en Direct3d ou OpenGL sur ces systèmes, juste la "composition des fenêtres", et quelques effets.
En tous cas, je suis sur que XGL fait comme ça.
L'arrivée d'une API gérant mieux la réalitée augmentée, le multithreading des IBM force42 à 512 GPU ou les ports Schriebmann ? Un rachat par Microsoft ? Gordon Freeman ?
L'API que je parlait d'inventer, c'était celle d'X.
Sinon "la 3d peut dessiner la 2d", je confirme. Par contre l'API 3d est pas nécessairement adaptée à la 2d (si tu me crois pas, fait un mini logiciel de dessin monochrome avec l'api OpenGL, avec une bonne API c'est 40 lignes de C sans subtilités).
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 5.
> http://linux.tlk.fr/traitement-graphique/
Très intéressant."surface 2D plate" : joli pléonasme.Ils ont raison. X n'a pas à singer Windows ou un autre. Il doivent rendre X meilleur. Si Windows a de bonnes idées, il faut les prendres.Donc singer Windows est une garantit de succès ? Regardes Gnome, il ne suit pas particuliairement Windows et pourtant Red Hat y est particulièrement impliqué. Mais Gnome ne s'écarte pas de Windows seulement pour le principe de s'écarter de Windows. Faudrait-il faire une ligne de commande pourrie car Windows à une ligne de commande pourrie pour avoir du succès ?
J'en doute sérieusement.
Si Firefox est un succès, ce n'est pas car il a singé I.E..
Bien sûr on ne peut ignorer la base utilisateur énorme de Windows et s'il est possible de leur facilité la prise en main de Linux sans nous "pervertir", alors faisons le.
Bien sûr Linux est en compétition avec Windows. Donc il faut regarder ce que font nos concurrents, c'est une bonne source d'inspiration, et nous étalonner par rapport à eux pour peut-être changer des priorités et l'"emporter".
Peut-être que le travail sur AIGLX/etc est pour suivre MS. Mais j'en doute car les bureaux sous Linux ont depuis longtemps un soucis d'esthétique (voir par exemple la souplesse des systèmes de thèmes et le nombre de thèmes disponibles).
L'intérêt actuel pour la 3D sous Linux est peu motivé par les jeux mais principalement orienté vers le bureau. Par exemple ça "cause" beaucoup plus à l'utilisateur de voir un bureau remplacé par un autre avec un animation lorsqu'il change de bureau que de voir un bureau qui disparait d'un coup et un autre qui apparait d'un coup.Dans Linux évidemment. L'histoire le montre et sans la moindre ambiguïté. Tout Linux tourne "full-root" (absolument aucune barrières) et peut mettre à genoux le système les doigts dans le nez. Un petit bout de X tourne sous root (je n'ai pas mis "full-root" car on est en userland) avec le minimum de privilège pour fait le nécessaire. Ainsi ce que peut faire X11 est encadré par le noyau et peut par exemple aussi être encadré par selinux (ce qui ne serait pas le cas si X tournait au niveau noyau). Ben pourquoi ils le font ? On peut toujours déplacé ce qui est fait en root dans le noyau. Mais où est le gain de sécurité là dedans ?
Le noyau est un élément hyper-critique. Moins on en met dedans (sans impact significatif sur les performances) et mieux on se porte.
Ca me fait penser à cette stupide nouvelle passée sur linuxfr au titre alarme de "Graves problèmes de sécurité dans x.org" :
http://linuxfr.org/2006/05/15/20813.html
Ici une superbe réponse :
http://marc.theaimsgroup.com/?l=openbsd-misc&m=114658731(...)
Et comme bien souvent, ces critiques viennent de "fans" d'OpenBSD qui veulent donner des leçons de sécurité.
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 2.
> http://linux.tlk.fr/traitement-graphique/Ca marche ! Je l'ai fait (2 claviers, 2 souries, 2 cartes graphiques et avec XFree86 version 4.? (j'ai oublié), pas de framebuffer). De plus il me semble que Mandrake vendait des systèmes avec 4 claviers, 4 souries, 4 cartes graphiques.
Evidemment, ça ne se fait pas sans difficultés et ce n'est pas la perfection. Mais on peut aussi comprendre que ça ne fasse pas parti des priorités les plus élevées des développeurs. Avec PCI express, ça va peut-être changer comme le souligne le document. ?????? Je doute très fort de cette affirmation. C'est pour le rendu des polices ???? Ce n'est pas ce qui est déjà fait ?
[^] # Re: Futur antérieur..
Posté par Bruno Ethvignot (site web personnel) . Évalué à 1.
Oui comme l'écrit Jon Smirl voilà un an, des rustines permettent de faire fonctionner le multiutilisateur sous X. Peut-être que des avancées ont été faîtes depuis un an ?
Si nous tenons à garder dans la conception des VT un raccourci-clavier pour sauter entre les pilotes vidéo, je pense qu'il serait juste d'implémenter un raccourci clavier pour sauter entre les pilotes disque et réseau.
C'est ironique, Jon Smirl trouve stupide que deux pilotes de périphériques, X et la console, essayent de contrôler le même matériel. Si on change le pilote vidéo par une combinaison du clavier, pourquoi ne pas aussi changer de pilote réseau par une combinaison clavier ;-) ?
Remplacer des parties de Mesa par des implémentations accélérées par le matériel, ce n'est pas ce qui est déjà fait ?
Bien entendu, mais tu dois remettre la phrase dans son contexte, Jon Smirl ne parle pas de l'implémentation actuelle, mais à quelle hauteur doit-être tracé la frontière du pilote de périphérique graphique et du modèle XGL (Xglx et Xegl)
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 1.
Je voulais dire que je ne vois pas en quoi la nécessité de quelques rustine permet de conclure à une erreur de conception de X11.
Son papier parle bien de la conception de X11 et non de tel ou tel bug ou manque mineur.
> mais à quelle hauteur doit-être tracé la frontière du pilote de périphérique graphique et du modèle XGL (Xglx et Xegl)
J'avais compris (du moins en gros, car je ne suis pas un spécialiste).
Ce qu'il propose est tout à fait cohérent et dans la logique de l'évolution du hardware. Il est peut-être trop en avance et a un peu moins à l'esprit les conséquences facheuses de "tout cassé" dans X11 pour en faire quelque chose de clean (longue période sans évolution de la branche stable, problème de compatibilité avec le vieux, comment garder un large base de développeurs/testeurs si ça explose de tous les côtés durant une longue période, on se coupe durant une longue période des projets utilisateurs (gnome, kde, etc), etc).
C'est peut-être un mal nécessaire avec un gros retour sur investissement. Je ne suis pas qualifié pour en juger.
[^] # Re: Futur antérieur..
Posté par Bruno Ethvignot (site web personnel) . Évalué à 3.
Jon Smirl n'écrit nulle part de « singer Windows » mais de créer une interface graphique compétitive. C'est-à-dire de créer une interface graphique sexy, rapide et réactive qui n'a rien à envier aux « concurrents ». D'un autre côté les interfaces graphiques sont nivelés sur tous les systèmes par la capacité des cartes graphiques, donc on doit retrouver les mêmes techniques d'affichage sur Vista, MacOSX et XGL. De plus Jon Smirl ne parle pas des fonctionnalités de bureau, mais de techniques d'affichage, peu importe que ce soit GNOME, KDE, XFCE ou même Wine qui utilisent ensuite ces techniques d'affichage.
Si Firefox est un succès, ce n'est pas car il a singé IE
Pour information l'objectif initial de Firefox était de créer les fonctions de l'interface utilisateur là où les utilisateurs d'IE s'attendent à les trouver.
Mais j'en doute car les bureaux sous Linux ont depuis longtemps un soucis d'esthétique (voir par exemple la souplesse des systèmes de thèmes et le nombre de thèmes disponibles)
Encore une fois Jon Smirl parle de techniques d'affichage pas de l'esthétisme des thèmes des différents gestionnaire de fenêtre. J'ai constaté que les interfaces graphiques basées sur Xorg sont moins réactives et ont des problèmes de rafraîchissement par rapport à une interface graphique basée sur la GDI de Windows dû en partie à des problèmes de latence de la Xlib (que devrait résoudre XCB j'espère).
Par exemple ça "cause" beaucoup plus à l'utilisateur de voir un bureau remplacé par un autre avec un animation lorsqu'il change de bureau que de voir un bureau qui disparait d'un coup et un autre qui apparait d'un coup.
« Beaucoup d'effets plaisants produits par la 3D peuvent juste être superficiels mais il y a également des raisons valables pour l'usage de la 3D »
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 2.
Parce que tu crois que Xorg essaie de faire un truc pas sexy et pas compétitif ?
Je crois qu'ils font de leur mieux, en fonction de la demande et des ressources disponibles, et que Windows soit à des années devant ou derrière ne change rien. Il y a des domaines où Linux est en avance et pourtant les développeurs ne font pas un pause pour attendre le train MS.
Par contre insister en disant "- Hé les gars vous est à la ramasse par rapport à Windows et vous avez tout faux", n'est pas les encourager.
> D'un autre côté les interfaces graphiques sont nivelés sur tous les systèmes par la capacité des cartes graphiques, donc on doit retrouver les mêmes techniques d'affichage sur Vista, MacOSX et XGL.
Mouaif. Pourquoi pas généraliser aux disques dures, aux cartes réseaux, aux claviers, à la mémoire, etc pour conclure que Linux, Vista, Mac doivent avoir les mêmes techniques dans tous les domaines.
Désolé d'être brutal, mais ton raisonnement me semble léger. Mais il n'est pas stupide.
> De plus Jon Smirl ne parle pas des fonctionnalités de bureau, mais de techniques d'affichage, peu importe que ce soit GNOME, KDE, XFCE ou même Wine qui utilisent ensuite ces techniques d'affichage.
Ben Gnome/etc a sa technique de gestion des widgets, a sa technique de "base de registre" (c'est pourtant stocké sur les même disques durs), etc... Le raisonnement de Jon Smirl doit être considéré vrai pour X11 mais il ne faut surtout pas l'appliquer ailleurs ?
Bizarre.
La voie tracée par MS n'est pas forcément la meilleur. Mais il faut reconnaitre que MS, et surtout toute l'expertise qu'il y a autour de MS (participation des fabricants de cartes graphiques, etc), ne doit pas être sous-estimée.
Ce que je veux dire en définitive, c'est que je me méfie énormément des critiques, envers des équipes qui gèrent des projets libres, du style "il y a qu'à, suffit de casser tout X11 et faire comme MS, etc". Des critiques comme ça il y en a une tout 3 ou 4 mois. L'équipe d'Xorg a une grande expertise et est aussi correctement entourée (pas autant que MS malheureusement). Ils suivent la voie qui leur paraissent la meilleur et ne se disent pas "on ne va pas faire comme Windows juste histoire de faire original". Ils doivent avoir de solides arguments.
Il y a déjà eu plus d'un fork de XFree avec des "vous allez voir ce que vous allez" et ... on vu. Certe, il y a le fork de XFree/Xorg, mais il ne compte pas vraiment car Xorg a été suivi par la majorité de l'équipe d'XFree. L'équipe d'Xorg a été dès le début surtout l'équipe d'XFree.
Je ne cherche pas à accabler Jon Smirl ou interdire toute critique. Son travail, sa réflexions, ses articles ont assurément allimenté la réflexion et le travail d'Xorg. En tout cas la lecture de son article est passionnante et je la conseille vivement.
> Pour information l'objectif initial de Firefox était de créer les fonctions de l'interface utilisateur là où les utilisateurs d'IE s'attendent à les trouver.
Parce que tu crois qu'ils allaient mettre le menu "fichier" à droite sans se rendre compte qu'à gauche c'est aussi bien et qu'en plus une large base d'utilisateur s'y retrouve ?
Les utilisateurs de Firefox ont eu les popups bloqués sans s'y attentre, et les tabs sans s'y attendre, etc.
Je répète ce que j'ai dit plus haut :
- "Bien sûr on ne peut ignorer la base utilisateur énorme de Windows et s'il est possible de leur facilité la prise en main de Linux sans nous "pervertir", alors faisons le."
> Encore une fois Jon Smirl parle de techniques d'affichage pas de l'esthétisme des thèmes des différents gestionnaire de fenêtre. J'ai constaté que les interfaces graphiques basées sur Xorg sont moins réactives et ont des problèmes de rafraîchissement par rapport à une interface graphique basée sur la GDI de Windows dû en partie à des problèmes de latence de la Xlib
Sur ce diagnostique, on est d'accord. Je ne suis pas convaincu que celà ait une importance énorme sur l'utilisateur. M'enfin quand il vient de Windows il le remarque et ça donne une mauvaise image.
Je ne suis pas convaincu que le MS ait choisi la conception de leur système graphique pour avoir des menus qui s'affiche en un millième de seconde. C'est la conséquence de leur "manie" de faire du "tout en un hardcodé" pour qu'il n'y ait pas d'alternative.
> « Beaucoup d'effets plaisants produits par la 3D peuvent juste être superficiels mais il y a également des raisons valables pour l'usage de la 3D »
J'ai bien vu/lu. Je voulais seulement dire que ce qui se passe autour de AIGLX/etc n'est pas motivé par les jeux où on va rechercher le maximum de performance.
[^] # Re: Futur antérieur..
Posté par djrom . Évalué à 8.
Dans le papier en question, il est mentionnée clairement que cette faille peut être utilisée pour contourner les systèmes de sécurité qui imposent des restrictions même à root, comme AppArmor, SELinux, ou les securelevels OpenBSD. Avec cette faille, on en revient au modèle Unix traditionnel que ces systèmes essayaient justement de remplacer. C'est assez gênant. Ah oui, sans oublier qu'il faut pas forcément être root, il suffit d'avoir les bonnes capacités d'accès au matos. Sur un système Linux moderne, ça veux pas forcément dire être root, vu qu'un gros effort à été fait pour permettre de modulariser toutes ces capacités que root a. On peux pas critiquer l'auteur du papier en disant "le gros naze, il a rien compris, il faut être root pour exploiter son truc", vu qu'il le dit lui-même, et que c'est justement un des interêts de ce papier: nous montrer les problèmes qui nous attendent pour foutre des nouveaux schémas de sécurité sur nos vieux Unix.
Pour résumer, on a une faille qui fout par terre tous les systèmes de sécurité "modernes" sur un système Unix, pour en revenir au bon vieux "root = dieu" qu'on essaie (dans le domaine de la sécurité avancée, genre pas les machines de bureaux) de mettre aux oubliettes. Ca concerne peut-être pas tes machines à toi, mais cette faille embête beaucoup de gens qui utilisent des Unix pour faire quelque chose de vraiment sécurisé. Pour ces gens là, c'est un "grave problème de sécurité", sisi.
PS: Ah oui, et les clichés sur les "fans d'OpenBSD", franchement ...
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à 1.
> Dans le papier en question, il est mentionnée clairement que cette faille peut être utilisée pour contourner les systèmes de sécurité qui imposent des restrictions même à root, comme AppArmor, SELinux
Pour exploiter cette faille afin de contourner AppArmor, SeLinux et autres, il faut déjà être root ! (dexit l'auteur du papier). Donc il faut déjà exploiter une autre faille. Et on peut supposer que cette autre faille ne contourne pas Selinux etc. Sinon qu'elle est l'intérêt de la faille découverte par Loïc Duflot ?
Quand je me loggue root sur ma bécane, je ne pense pas qu'exploiter une faille de X11 me donne encore plus accès à ma bécane. Et toi ?
> il suffit d'avoir les bonnes capacités d'accès au matos.
Et pour ça tu fais comment ?
Ben j'installe un serveur X11 cracké (ou un programme qui active la faille) qui permet d'exploiter la faille X11.
Et pour ça tu fais comment ?
Ben il me faut un compte root.
Et pour avoir ce compte root tu fais comment ?
Ben il me suffit d'avoir les bonnes capacités d'accès au matos.
Et pour ça tu fais comment ?
Ben j'installe un serveur X11 cracké (ou un programme qui active la faille) qui permet d'exploiter la faille X11.
Et pour ça tu fais comment ?
Ben il me faut un compte root.
Et pour avoir ce compte root tu fais comment ?
etc... Je te laisse complèter la suite.
> Sur un système Linux moderne, ça veux pas forcément dire être root
En un sens c'est vrai. Mais comment tu fais, toi le cracker de haut volé, pour être en position d'exploiter la faille des programme qui ont un accès matos d'un certain niveau ?
Il ne te faudrait pas comme qui dirait déjà un autre GROS trou de sécurité ?
Oui.
Un trou de sécurité assez gros qui te permet :
1- d'avoir accès au hardware
2- d'injecter des commandes arbitraires car les commandes envoyées par X11 ne sont évidemment pas des commandes pour obtenir root.
Enfin il faut exploiter cet autre GROS trou de sécurité avec selinux, etc actifs car l'attaque "fatale" n'a pas encore eu lieu.
> Avec cette faille, on en revient au modèle Unix traditionnel
Encore faut-il être en position exploiter cette faille ce qui n'est pas une mince affaire. Donc, je répète, il faut le faire en deux phases et pour la première phase, on ne sait RIEN.
> On peux pas critiquer l'auteur du papier en disant "le gros naze, il a rien compris, il faut être root pour exploiter son truc",
Si, on peut et on doit.
On a vu que pour exploiter cette faille, il faut un autre trou de sécurité qui permet d'accéder à root afin de cracker X11 pour pouvoir exploiter la faille.
Avec ce type de prérequis, je te trouve des "graves problèmes de sécurité" dans rpm/apt, login, etc, tout ce qui tourne en root (même temporairement) ou pas en root d'ailleurs (la suppression des données personnels est très grave).
Avec ce type prérequis, je peux faire qu'à chaque fois que tu lances rpm en root, il supprime tout (un gros "rm -r -f /" qui tache).
La supercherie de l'article, c'est que pour dénoncer un trou de sécurité potentiel, il faut en passer par un trou de sécurité large comme le pacifique, et ce dernier est passé sous silence (normal, il n'a pas été trouvé).
Il y a foutage de gueule de dire qu'un trou de sécurité potentiel est grave si et seulement si le système est une vraie passoire.
> Pour ces gens là, c'est un "grave problème de sécurité", sisi.
Ben tu diras à "ces gens là", qui ont une haute conscience de la sécurité, de mettre un ticket dans CVE car il n'y en a pas.
> PS: Ah oui, et les clichés sur les "fans d'OpenBSD", franchement ...
Et ça c'est mieux :
http://linuxfr.org/2006/05/15/20813.htmlSelon wikipedia, il bosse pour *BSD. Mais il fait des commentaires sur Linux et Xorg. Bizarre non ? Il "est connu pour ses positions conflictuelles et sans compromis, ce qui a contribué à plusieurs disputes au sein de la communauté du logiciel libre"Quand on voit le nombre de fois que Xorg et ces "distributions commerciales" ont cassé la compatibilité avec les pilotes propriétaires, ça fait bien rire. Si en plus on sait qu'OpenBSD utilise Xorg alors qu'ils sont un constributeur marginal...Le point est intéressant. Si t'as le thread sur freedesktop.org qui a discuté sur ce point, donnes le. Mais je ne vois pas en quoi c'est une solution pour ce problème. Débord, X11 a besoin d'accéder au hardware, donc ce système ne sera pas utiliser pour empécher l'accès au hardware. Enfin, la faille courcircuite tous les systèmes de sécurité (on peut faire exécuter n'importe quoi par le noyau). Donc je ne vois pas comment ça empêche de faire l'attaque et une fois l'attaque faite, ça ne sert à rien.Mais quel bande de fainiasses tu vas dire. Normal qu'ils ne fassent rien, il n'y a rien à faire pour ce cas précis.Vas expliquer avec ça que Linux est un système sûr si la moindre interface graphique fait courir un risque grave à ton buziness. Je ne serais pas étonné qu'il y ait ici encore un troll OpenBSD s'ils ne lancent pas Xorg par défaut.Et élitiste avec ça...
[^] # Re: Futur antérieur..
Posté par djrom . Évalué à 2.
Il faut exploiter une autre faille ? Et donc ? Les failles deviennent souvent dangereuses en combinaison, c'est assez rare les failles "arg, n'importe qui peut devenir root à distance". Plus souvent, t'exploite déjà une failledistante qui te donne un accès apache genre, et après t'exploite une faille locale qui te permet de devenir root.
Ah oui, et puis "devenir root" n'exige pas forcément une faille. Tu peux souhaiter que l'utilisateur légitime de root n'aie pas accès à certaines choses, et c'est justement l'interêt de ces systèmes de sécurité.
L'idée c'est que pour obtenir un système Unix un peu plus sécurisé de nos jours, on utilise deux systèmes de sécurité: le mécanisme standard des utilisateurs Unix, et un mécanisme en plus (genre AppArmor, SELinux, securelevels, ...), le mécanisme en plus permettant de limiter les possibilités plus finement, et même pour les personnes en haut de l'échelle Unix normale (genre root ou sudoers). Cette faille fout en l'air ça.
*Ta* bécane, non. Mais une bécane utilisant SELinux pour limiter les possibilités de root, si. Et dans ces cas là, cette faille est vraiment génante.
Je développe ce que je voulais dire, parce que visiblement on s'est pas compris.
Quand je disais ça, je voulais dire que y'a des tonnes de mécanismes sur un Linux moderne qui permettent à un logiciel d'avoir une partie seulement des pouvoirs de root, sous la formes des capacités par exemple. Typiquement, t'utilise ça en combinaison avec pam pour permettre à tel ou tel programme de se lancer en mode realtime, ou d'avoir accès à un matos précis, ...
Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root. C'est pas développé dans le papier, parce qu'il s'intéresse pas à Linux en particulier, mais il suffirait de jeter un oeil plus précisément pour trouver. Et qui sait si genre cdrecord, ou je ne sais quel programme utilisant le hardware en mode bas-niveau n'a pas ces capacités là.
Et puis sinon, y'a une autre méthode assez bête: exploiter une faille dans un programme suid root.
Et là, on en revient à ce que je disait, les trucs genre SELinux sont conçus précisément pour éviter qu'une personne exploitant une faille pour devenir root soit le maître de la machine. Avec cette faille c'est foiré. Et j'ai pris SELinux, mais y'a des tonnes de choses de ce genre, genre jail(), les vservers, UML, ... A priori, cette faille peut les foutre par terre.
Libre à toi de considérer "y'a une faille qui permet de passer root en local" est l'équivalent de "le système est une vraie passoire". Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités. Cette faille bousille ça, ça m'embête.
La chose est simple: des failles qui permettent de passer root, y'a en tout le temps. Des failles qui permettent de passer les systèmes de sécurité "alternatifs", y'en a très peu souvent, voire même quasiment jamais. Et cette faille, c'est un trou béant. Donc elle a de l'importance.
Ben oui, parce que le type est chercheur en sécurité, alors il va pas expliquer comment exécuter du code en tant que root sur une machine Unix, ce serait assez inintéressant.
Pour cette histoire avec Théo de Raadt, effectivement il bosse pour OpenBSD, c'est même le leader et développeur principal, alors le qualifier de "fan d'OpenBSD" ... Le fond je sais pas, j'ai pas lu le thread.
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à -2.
Sauf qu'ici il faut :
(A)- exploite d'une faille qui permet de devenir root
(B)- exploite de la faille X11
Aujourd'hui (A) n'existe pas. Donc corriger (B) ne sert à rien. Selon les mailings de freedesktop, corrigier (B) est un boulot considérable et qui peut impacter les parformants du système.
Imaginons que (A) existe, ce qui arrivera tout ou tard. Si (A) est utilisé, t'as au moins 5000 façons différentes pour tout péter. Si (B) est colmaté, il n'en reste "que" au moins 4999.
Si pour toi un système donnant 4999 chances sur 5000 de tout péter est sûr, alors t'y comprend rien.
> un mécanisme en plus (genre AppArmor, SELinux, securelevels, ...), le mécanisme en plus permettant de limiter les possibilités plus finement, et même pour les personnes en haut de l'échelle Unix normale (genre root ou sudoers). Cette faille fout en l'air ça.
Il y a une méprise très grave sur ce qu'est selinux ici. SeLinux ne se substitue pas au modèle traditionnel de sécurité d'Unix. Il le complète seulement (et fort éfficacement).
A celà plusieurs raisons (liste non exhautive):
1- Il n'y au aucun compatibilité entre selinux et le système tradionnel. Si les protections du fichier n'autorise pas l'excécution d'un programme et que selinux l'autorise, le programme n'est pas excécuté.
2- Selinux n'est pas actif dès que le noyau est up contrairement au système traditionnel.
3- Selinux est désactivé lorsqu'on fait un fsck de la partion racine (donc on peut lire et excéuter tous les fichiers permis par le système traditionnel)
4- Il est nécessaire de désactiver selinux pour faire un relabel.
5- Dans un contexte réseau avec des serveurs NFS (voir samba) il faut faire coabiter des machines avec selinux et des machines sans. Les machines sans ne s'appuis que sur le système traditionnel.
6- Tous les systèmes de fichier ne supporte pas selinux
7- Le système doit rester sûr sans selinux (certe moins)
8- Il y a des systèmes sans selinux
9- la sécurité des programmes est conçue sans selinux. Dès que selinux est réveillé, la situation est anormale et il y a probablement un grave problème. La situation ne doit en aucun cas perdurer (que (B) soit exploitable ou non).
Donc il ne faut surtout pas dire :
- "corrigé (B) car selinux sera inopérant si (B) arrivé, et ignoré (A) car selinux s'en charge".
Surtout que le constexte selinux change. Si un programme lancé à distance (par exemple via ssh) peut être inoffensif si selinux est "dur" avec les connections distances, il n'en sera pas forcément de même si root le lance depuis la console par inadvertance.
Selinux n'est pas une solution qui annihile (A) et le rend tolérable !
De plus il y a nombre de chose que Selinux ne peut détecter. Par exemple un exploit sur une base de données qui ensuite demande d'effacer toutes les tables. Dans ce cas là, selinux ne voit RIEN.
Donc atteindre (B) via (A), même avec selinux, ne rend pas pas (A) "gentil".
De plus, colmater (B) alors que (A) peut faire joujou avec le matériel (effacer un disque ?), vider une base de données, innonder le réseau avec des données confidentiels, saturer /tmp, que sais-je encore, est limite accessoire.
Car le contexte de (A), il veint d'où ? Il vient d'un autre programme. Ce programme a à l'évidence une fonction. Pour mener à bien cette fontion, il doit probablement avoir besoin de lire des fichiers, d'en écrire, de faire des connections internets, etc. Selinux est configuré pour permettre à ce programme de bosser et laissera (A) faire des dégâts (certe moins que sans selinux).
> Typiquement, t'utilise ça en combinaison avec pam
Pam c'est pour l'authentification et dans le cas où tu peux diminuer les privilèges *avant* que le programme s'exécute. Le programme faisant peut-être d'autres cap_drop après sont initialisation.
Un fonctionnement typique est :
- pam donne des privilèges (en fait restreint, mais comme il peut ne rien donner, on peut considérer qu'il donne des privilèges).
- le programme en supprime avec cap_drop
> Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root.
Mais il faut aussi un autre gros trou de sécurité. Que la "bonne" combinaison de capacité n'est pas suffisant. Et l'autre gros trou de sécurité il en fera des dégâts avant même qu'il pense à utiliser l'exploit X11.
> C'est pas développé dans le papier, parce qu'il s'intéresse pas à Linux en particulier, mais il suffirait de jeter un oeil plus précisément pour trouver.
Ben les experts de Xorg on jeté un oeil et n'ont rien trouvé. Je ne crois pas que tu sois plus futé que les experts de Xorg, ni plus futé que les experts de CVE qui n'ont rien trouvé.
> Et qui sait si genre cdrecord
Si genre un cdrecord qui a été piraté et pas un cdrecord normal. Si ton cdrecord a été piraté, je me fairais de gros gros soucis que (B) soit exploité ou non. Car il faut quoi pour pirater cdrecord ? Les droits root.
Au fait, cdrecord peut s'utiliser sans setuid. C'est comme ça depuis au moins 2 ans.
> exploiter une faille dans un programme suid root.
Dans ce cas pourquoi te faire chier avec (B) si t'as déjà (A) (un accès root).
Si t'as (A), tu peux avoir (B) et (C) et (D) et ... (ZZZ).
Pourquoi tu fais cette fixation sur (B) ?
> les trucs genre SELinux sont conçus précisément pour éviter qu'une personne exploitant une faille pour devenir root soit le maître de la machine.
Ca atténue le problème, ce n'est pas une solution.
> Avec cette faille c'est foiré.
Avec seulement (A) (qui a des droits root) c'est déjà foiré. Prépares toi à sortir les backups.
> Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités.
Très grave erreur.
> Et cette faille, c'est un trou béant.
Ce n'est pas l'avis d'xorg et du CVE. Il n'est même béant le trou, il n'existe pas.
Puisque tu affirmes qu'il est béant, prend contact avec CVE :
http://cve.mitre.org/
> le qualifier de "fan d'OpenBSD"
Je ne pensais pas à lui, mais à celui qui a fait la news et/ou celui/ceux qui l'a/ont validé.
[^] # Re: Futur antérieur..
Posté par djrom . Évalué à 2.
Pfff, t'as moyen de faire sans l'aggressivité ?
Est-ce que j'ai dit le contraire ?
Est-ce que j'ai dit le contraire ?
Bon ben trop d'aggressivité pour moi, et j'ai pas l'impression qu'on arrive à se comprendre. Alors t'aura qu'à avoir raison, et moi j'aurais qu'à "rien avoir compris", et pis voilà. Tcho !
[^] # Re: Futur antérieur..
Posté par clearstream . Évalué à -3.
Désolé. Mais que veux tu...
Tous les spécialistes (sauf deux ou trois mecs d'OpenBSD) disent qu'il n'y a pas de trou de sécurité, bien qu'ils s'accordent à dire que l'architecture actuelle n'est ni idéale ni très propre mais est là pour des raisons pragmatiques (performance, portabilité, facilité de développement/debuggage, etc).
Il n'y a pas d'entrée dans le révérentiel CVE !!!
Et toi tu persistes à dire qu'il y a un trou béant dans Xorg !
En un sens tu discrédites Xorg et Linux sans motif valable et ça me tape sur le système.
Mon intention initiale n'était pas d'être désagréable.
A+, amicalement.
# Pour ATI c'est perdu
Posté par Drake . Évalué à 5.
"Proprietary, patented optimizations are part of the value we provide to our customers and we have no plans to release these drivers to open source,"
"In addition, multimedia elements such as content protection must not, by their very nature, be allowed to go open source."
Traduction à la volé : "Les optimisations brevetés et propriétaires sont une partie du produit que nous fournissons à nos clients et nous n'avons pas de plan pour libérer nos pilotes"
"Par ailleur, les composants multimédias qui ont des parties protégé ne peuvent pas , par leur nature, etre libéré". Ils parlent ici des sorties télés j'imagine (avec le système macrovision).
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 3.
Que ceux qui ont un doute en l'incompatibilité DRM/libre méditent (hein Pas Bill Pas Gates ?).
> Ils parlent ici des sorties télés j'imagine
Et probablement vidéo. Comme ça on ne peut pas récupérer le flux d'une vidéo (dvd, etc).
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 0.
Bonne nouvelle, t'es passé de GPL à "la definition meme d'un soft libre".
Il ne reste plus qu'une étape, c'est de parler d'incompatibilité libre/brevet au lieu de dire que le libre empêche les brevets.
Vu ta vivacité d'espris, ça va ne prendre que 2 ou 3 ans.
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 1.
Vu que la definition d'un soft libre est tiree en bonne partie de la GPL (qui represente l'enorme majorite des softs libres) ca coulait de source, mais visiblement pour certains c'est trop complique a comprendre.
Il ne reste plus qu'une étape, c'est de parler d'incompatibilité libre/brevet au lieu de dire que le libre empêche les brevets.
Incompatible oui, du fait du contenu de la licence. Mais ca tu le comprendras le jour ou tu reflechiras deux secondes et te rendra compte que ces licences ont ete ecrites en connaissant l'existence des brevets et qu'elles en ont fait fi.
[^] # Re: Pour ATI c'est perdu
Posté par briaeros007 . Évalué à 5.
d'ailleurs c'est bien connu , les bsd, les mit et les wtf c'est pas libre ...
Ce qu'il faut pas entendre...
Incompatible oui, du fait du contenu de la licence. Mais ca tu le comprendras le jour ou tu reflechiras deux secondes et te rendra compte que ces licences ont ete ecrites en connaissant l'existence des brevets et qu'elles en ont fait fi.
Je crois que surtout tu ne connais rien au brevet.
Tu peux trés bien faire un code libre qui utilise un brevet , ce sont deux choses complètement différentes.
Le brevet demande de payer des royalities/t'interdis de distribuer le binaire si tu l'utilise (de manière non-expériementale en europe, donc la distribution en code source est bonne \o/ ). Le brevet ne t'interdis pas de diffuser le code source a tes clients .
Bref comme tu dis 'Le jour ou tu reflechiras deux secondes' ...
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 1.
Le brevet demande de payer des royalities/t'interdis de distribuer le binaire si tu l'utilise (de manière non-expériementale en europe, donc la distribution en code source est bonne \o/ ). Le brevet ne t'interdis pas de diffuser le code source a tes clients .
Le brevet tu ne sais rien de ce qu'il permet car c'est le detenteur du brevet qui fixe les regles.
Comme tu dis, ce serait bien que tu reflechisses 2 secondes.
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 4.
Parce que la BSD peut-être libre et propriétaire. Quand un programme sous licence BSD a un brevet, ça devient un programme propriétaire.
http://www.fsf.org/licensing/essays/bsd.html
Donc un programme sous BSD, avec ou sans les sources, mais qui utilise un brevet n'est pas un logiciel libre. Sauf modification spécifique des conditions d'utilisation du brevet. Il n'y a que les brevets qui peuvent débloquer la situation.
> Le brevet tu ne sais rien de ce qu'il permet car c'est le detenteur du brevet qui fixe les regles.
Tout à fait. Et ces brevets ont priorité sur le droit d'auteur. Et après tu vas dire que les licences libres font exprès d'être incompatible avec les brevets alors qu'elle n'ont que le choix de subir les brevets et que les brevets, eux, peuvent faire fi des licences (et non le contraire contrairement à ce que tu affirmes).
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 3.
Par défaut : NON.
Il faut que celui qui dépose le brevet est pris des dispositions particulières. C'est-à-dire pas de restriction d'utilisation par le logiciel libre. C'est rarement fait et uniquement par les "amis" du logiciel libre (Red Hat, Novell, IBM, Intel, etc). Pour IBM et Intel, ce n'est pas pour tous leurs brevets, mais pour quelqu'un. M'enfin, c'est mieu que rien.
> donc la distribution en code source est bonne
Par défaut, un brevet ne t'interdit pas de diffuser un programme qui l'utilise (que ce soit en binaire ou source). Par contre, il t'interdis de l'utiliser sans l'accord du détenteur ! C'est fondamentalement incompatible avec le logiciel libre.
> 'Le jour ou tu reflechiras deux secondes' ...
Ben réfléchis aussi un peu.
[^] # Re: Pour ATI c'est perdu
Posté par briaeros007 . Évalué à 2.
Restriction qui ne peut avoir lieu si on distribue en code source, vu qu'il s'agit de version expérimentale, et que dans ce cas , les restrictions du détenteur ne s'applique pas.
donc par défaut : OUI (en france en tout cas)
Par contre, il t'interdis de l'utiliser sans l'accord du détenteur ! C'est fondamentalement incompatible avec le logiciel libre.
Ah non non non.
Le brevet 't'interdis' (sous conditions) d'utiliser tel ou tel technique . toutefois , dans le cadre d'une expérimentation les restrictions n'ont plus court.
Si tu le diffuse en source, chaque utilisateur le compile donc lui même, et il fais donc de l'expérimentation, et par conséquent , le détenteur peut se mettre son brevet la ou je pense.
bon ensuite faut etre bien sur que si on le récupère en source c'est pour de l'expérimentation , mais ca doit pas etre trop dur a montrer vu que tous les prgrammes propriétaires utilisent des binaires , il est aisé de démontrés que c'est pas la solution 'normale et efficace', et que c'est plus proche d'une 'Méthode scientifique exigeant l'emploi systématique de l'expérience' (où l'expérience est la modification et la compilation des sources, par exemple pour voir si ca compile bien chez nous).
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 2.
Code source ou pas, les brevets ne t'interdisent pas directement de distribuer. Par contre sans accord du détenteur, tu ne peux pas utiliser le logiciel.
A partir de quand, c'est expérimental ?
Enfin on parle des utilisations (le plus grand nombre) ou des chercheurs (une minorité) ?
> Ah non non non.
> Le brevet 't'interdis' (sous conditions) d'utiliser tel ou tel technique .
Les brevets d'interdisent toujours de les utilisers. Il faut l'accord explicite du détenteur.
Si quelqu'un pose un brevets, sans accord explicite du détenteur, il est interdit d'utiliser le brevet.
http://fr.wikipedia.org/wiki/Brevet
> Si tu le diffuse en source, chaque utilisateur le compile donc lui même, et il fais donc de l'expérimentation, et par conséquent , le détenteur peut se mettre son brevet la ou je pense.
Ben je vais m'installer une Gentoo.
Tu rèves.
[^] # Re: Pour ATI c'est perdu
Posté par briaeros007 . Évalué à 2.
Code source ou pas, les brevets ne t'interdisent pas directement de distribuer. Par contre sans accord du détenteur, tu ne peux pas utiliser le logiciel.
Ben si.
toujours si tu fais de l'expérimentation, tu peux utiliser le logiciel sans accord du détenteur du brevet.
A partir de quand, c'est expérimental ?
Enfin on parle des utilisations (le plus grand nombre) ou des chercheurs (une minorité) ?
J'ai rien trouvé dessus :(
Mais si on autorise une personne lambda de faire des expérimentations, pourquoi on empecherais n personnes de faire des experimentations ? ;)
il est interdit d'utiliser le brevet.
sous certaines conditions qui sont posé dans la loi (autorisation dans le cadre de l'expérimentation par exemple).
Ben je vais m'installer une Gentoo.
Trés bonne distrib.
Tu rèves.
toujours mieux que de pleurer, et jusqu'a présent rien n'indique que je rêve, sinon que 'non c'est pas comme ca ca peut pas marcher' , ce qui , comme argument est un peu faible.
Bref j'ai pas forcément raison, mais pas forcément tort non plus ;)
[^] # Re: Pour ATI c'est perdu
Posté par Vador Dark (site web personnel) . Évalué à 2.
[^] # Re: Pour ATI c'est perdu
Posté par briaeros007 . Évalué à 2.
puis faut bien faire des tests exhaustifs pour être sur que ca marche ;)
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 0.
Du fait aussi des brevets. Donc c'est incompatible.
> te rendra compte que ces licences ont ete ecrites en connaissant l'existence des brevets et qu'elles en ont fait fi.
Et comment tu fais toi qui est si malin pour faire une licence libre qui accèpte les brevets logiciels ?
T'as déjà répondu à cette question ailleurs :
- Tu ne sais pas faire
- Ou tu proposes de passer la licence libre en licence propriétaire (brillant...)
Et puis arrêtes de mentir sans arrêt. Les brevets logiciels ont été effectif autour de 1995. Dexit wikipedia. Si t'es pas d'accord, vas mettre à jours wikipedia. Donc les brevets logiciels ont existé bien après le logiciel libre. Tout les licences avant 1995 (dont la GPL) ont été faites sans connaitre l'existence des brevets logiciels tel que accèpté aujourd'hui (c-à-d possibilité de breveter une fonctionnalité et non un moyen pour obtenir une fonctionnalité ; ce qui a été introduit par les brevets logiciels et qui ne se trouvait nul par ailleurs). Pourtant elles sont toutes incompatible avec les brevets. Les brevets logiciels ont été fait en connaissant les licences libres et ont été faits incompatibles avec le logiciel libre.
Tant que tu ne montreras pas une licence libre compatible avec les brevets logiciels, tu ne feras que démontrer que tu es un putain de gros menteur.
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 3.
Mais justement je ne la fais pas, si tu lis ce que j'ecris plutot que delirer tu verras que c'est clair :
Incompatible oui, du fait du contenu de la licence
T'as du mal a comprendre ces qqe mots on dirait.
Et puis arrêtes de mentir sans arrêt. Les brevets logiciels ont été effectif autour de 1995. Dexit wikipedia. Si t'es pas d'accord, vas mettre à jours wikipedia.
Comme tu es rigolo, allez je prends ton cher Wikipedia : http://en.wikipedia.org/wiki/Software_patent
The first software patent ever granted is probably a patent for a "computer having slow and quick access storage, when programmed to solve a linear programming problem by an iterative algorithm, the iterative algorithm being such that (...)" applied for in 1962 by British Petroleum Company
Encore un autre exemple, la patente sur l'algo LZW : http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec(...)
December 10, 1985
Et evidemment, le fait que les licences mentionnent les brevets et leur effet potentiel prouve sans equivoque que les auteurs de ces licences savaient parfaitement a quoi s'en tenir.
Serieusement, arretes de te ridiculiser.
Tant que tu ne montreras pas une licence libre compatible avec les brevets logiciels, tu ne feras que démontrer que tu es un putain de gros menteur.
Tant que tu ne montreras pas l'inverse de ce que tu dis tu ne feras que demonter que tu es un gros mechant nananereuh !!!
Ca c'est une traduction de ce que tu viens de dire.
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 2.
Incompatible oui, du fait de la nature même des brevets. Usage exclusif qui surpasse les droits d'auteurs.
D'ailleurs les brevets sont parfois incompatibles avec le logiciel propriétaire. Un freeware est souvent propriétaire mais comme c'est gratuit, c'est incompatible avec les brevets.
Mieux, un logiciel propriétaire et payant peut aussi être incompatible avec un brevet. Le détenteur du brevet peut refuser d'accorder une licence car c'est un concurrent, peut dire que son brevet ne doit pas être utilisé dans les gestionnaires de base de données, etc...
Le brevet l'importe tout le temps et quelque soit le contenu de la licence (libre ou pas).
Ce n'est pas du fait du contenu de la licence, mais parce que c'est un logiciel libre que c'est incompatible avec les brevets. Quelque soit le contenu de la licence, si c'est un logiciel libre, c'est incompatible avec les brevets. Quelque soit le contenu de la licence, même si ce n'est pas un logiciel libre, ça peut être incompatible avec un brevet. Tout dépend de la bonne volonté du détenteur du brevet et quelque soit le contenu de la licence.
> http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec(...)
> December 10, 1985
Certe, mais les brevets logiciels ont toujours été refusés par la justice américaine jusqu'en 91 (il y a eu quelques proces sur ça). La justice, pas forcément l'organisme qui enregistre les brevets. Entre 91 et 95, il y a eu une zone de flou car le sujet était à l'étude. Puis c'est depuis 95 que les brevets logiciels sont valides devant la justice américaine.
En 1985 aux USA, c'est comme aujourd'hui en europe. Tu pouvais déposer un brevet logiciel, mais en cas de procès il n'était pas reconnu. Ca a changé en 1995 aux USA, et heureusement ça n'a toujours pas changé en Europe.
Je peux te montrer un (même plus de 30 000) brevet logiciel de l'EBO, mais il n'est pas valide.
> Et evidemment, le fait que les licences mentionnent les brevets et leur effet potentiel prouve sans equivoque que les auteurs de ces licences savaient parfaitement a quoi s'en tenir.
Mais propose une licence libre qui accèpte les brevets logiciels toi qui est si malin !
Puis la GPL, indique les brevets à titre d'exemple.
Ce n'est pas interdire les brevets logiciels pour le plaisir, c'est interdire lles brevets logiciels pour que le programme reste libre !
Notes que si tu remplaces "patent" par "tarte à la crème", les brevets ne sont toujours pas compatibles avec le logiciel libre. Notes aussi, que ça n'interdit pas explicitement les brevets ni ne préjuge de comme peut-être exploité un brevet. Ca interdit les brevets SI ET SEULEMENT SI ca le rend incompatible avec la définition de logiciel libre. C'est pour celà qu'il y a des brevets de RedHat/IBM/Intel/etc dans les logiciels libres (sous licence GPL et autres) car le logiciel libre n'interdit pas les brevets mais une exploitation des brevets (ou autre) qui rendrait le logiciel non libre.
Puis arrêtes de prendre les gens pour des cons !
Si la fsf (ou RedHat, ou Novell, etc) pouvait faire une licence libre qui est compatible avec les brevets logiciels, ils l'auraient fait et sans se faire prier. Pour autoriser l'utilisation de brevets dans le logiciel libre, il faut que le détenteur du brevet l'autorise explicitement. Il n'y a pas d'autre moyen. Et toi qui te prétent malin, tu n'as jamais donné d'autres moyens.
> Serieusement, arretes de te ridiculiser.
Ils sont tous comme toi chez MS ?
Je veux dire le doigt sur la coupure. Toujours près à colporter le FUD de MS.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . Évalué à 4.
et puis, ati va bientôt subir une forte restructuration de la part d'AMD, les personnes assises aujourd'hui à nous affirmer que rien ne sera libéré ne seront peut-être plus à la même place demain...
[^] # Re: Pour ATI c'est perdu
Posté par hervé Couvelard . Évalué à 4.
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 3.
D'un autre cote, je suis pas sur qu'ils se soucient tant que ca de l'opinion d'une minorite infime de la population.
[^] # Re: Pour ATI c'est perdu
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Combien d'entre nous montent des PCs pour la famille, les amis... ou les coseillent sur le choix ?
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Pour ATI c'est perdu
Posté par Jean-Philippe (site web personnel) . Évalué à 4.
[^] # Re: Pour ATI c'est perdu
Posté par Vador Dark (site web personnel) . Évalué à 1.
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Pour ATI c'est perdu
Posté par vrm (site web personnel) . Évalué à 0.
[^] # Re: Pour ATI c'est perdu
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Pour ATI c'est perdu
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Je ne sais pas qui fait le choix du matériel, mais si les gens qui font l'installation des postes Linux ont leur mot à dire, je ne trouve pas ça illogique, pour au moins deux raisons :
1) s'ils installent des postes Linux, on peut peut-être penser qu'ils sont un peu libristes, et qu'ils préféreront des cartes disposant d'un pilote libre
2) c'est quand même beaucoup plus simple d'avoir un pilote intégré au noyau / à X.org pour tout ce qui est installation / mise-à-jour / maintenance...
[^] # Re: Pour ATI c'est perdu
Posté par Psychofox (Mastodon) . Évalué à 2.
Une grande (immense même) majorité des pc récents utilisés dans les administrations du monde entier sont des modèles de bureau standards des compagnies comme HP, Dell, Fujitsu-Siemens etc...et la plupart de ces pc sont équipés d'une carte graphique intel intégrée à la carte mère.
Pour avoir travaillé dans le secteur publique, seules les utilisateurs "spéciaux" (direction, grands professeurs d'université...) ou des utilisateurs ayant des besoins spécifiques (imagerie, etc...) disposent de stations de travail avec des carte graphiques différentes des simples carte intégrées
Dans l'administration, on trouve ce genre de modèles par exemple :
http://h20195.www2.hp.com/V2/GetDocument.aspx?docid=0900a5a5(...)
http://www1.euro.dell.com/content/products/compare.aspx/opti(...)
http://extranet.fujitsu-siemens.com/france/public/fp/pcs/fp_(...)
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . Évalué à 2.
Si ce sont des pc business à base Intel, ce sont généralement des chips graphiques intel, parfois ati voir nvidia.
Si ce sont des pc business à base AMD, ce sont majoritairement des chipsets graphiques ATI, et éventuellement nvidia.
[^] # Re: Pour ATI c'est perdu
Posté par Psychofox (Mastodon) . Évalué à 1.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . Évalué à 4.
Les administrations et grandes entreprises croient surtout leurs fournisseurs. Si HP ou IBM dit que les amd sont bons, et offrent de bonnes conditions, les entreprises achètent amd. L'important, ce n'est pas la marque de cpu (sauf pour certains religieux), mais leurs possibilités et surtout l'intégration dans une plateforme orientée entreprise.
[^] # Re: Pour ATI c'est perdu
Posté par Psychofox (Mastodon) . Évalué à 1.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . Évalué à 2.
Non seulement les amd sont présents dans les gammes des constructeurs, mais ils se vendent... la preuve, au boulot (institution financière assez conservatrice avec env 30.000 pc's), toutes les nouvelles machines de bureau sont des amd64, et les thin clients sont à base Athlon XP-M.
[^] # Re: Pour ATI c'est perdu
Posté par Psychofox (Mastodon) . Évalué à 2.
je te renvoies la balle, j'ai précisé plus haut que j'avais bossé jusqu'à très récemment dans le secteur publique. Toi tu me donnes comme exemple une institution financière privée. Je ne vois pas le rapport.
[^] # Re: Pour ATI c'est perdu
Posté par ragoutoutou . Évalué à 3.
Pour laquelle j'avais naïvement cru bon de préciser les combinaisons les plus fréquentes de combinaisons proc/chipset dans les pc's visant les grandes entreprises et administrations.
De là on en est arrivé à l'étape où tu déclares
Alors, à part le cas où tu me montres un appel d'offre spécifiant explicitement que l'administration exige des processeurs de marque Intel (ce qui serait sans doutes illégal), impose qu'une technologie comme l'hyperthreading soit présente (meilleur moyen de virer amd en douce dans un appel d'offre biaisé), ou des exemples d'offres qui ont été refusées sur base du fait que le processeur proposé dans l'offre était un amd, tes déclarations sont non-fondées.
[^] # Re: Pour ATI c'est perdu
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806(...)
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 1.
Puis Intel est bien obligé de respecter la lois. Intel ne peut pas rendre plus de source libre.
[^] # Re: Pour ATI c'est perdu
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Je me demande quand meme quelles seront les applications pratiques de ce truc sous un systeme libre, justement...
[^] # Re: Pour ATI c'est perdu
Posté par clearstream . Évalué à 2.
C'est toujours pour les trucs type DRM. Le flux est crypté quand il passe dans Xorg et décrypté dans la carte.
Je sais, c'est un horreur.
[^] # Re: Pour ATI c'est perdu
Posté par Croconux . Évalué à 2.
Oui, enfin, la protection des contenus ça ne doit pas trop les perturber. A une époque sous windows les drivers ATI contenaient une DLL à part chargée de gérer le Macrovision dans la lecture DVD et nommée d'une façon bien reconnaissable. il suffisait de l'effacer et zou plus de Macrovision. Tout avait été fait pour que la bidouille soit réalisable par n'importe qui, un peu comme les lecteurs DVD dézonnables en appuyant sur 3 touches de la télécommande. Donc à mon avis, ils sont tenus de mettre en place ces protections mais ça les emmerdent autant que les utilisateurs. Combien on parie que sur les carte munie de sortie HDMI il y aura dans le driver une DLL appelée "hdcp.dll" à supprimer ? Et pourquoi ne pas simplifier encore et l'appeler "remove_me_to_disable_hdcp.dll" ?
[^] # Re: Pour ATI c'est perdu
Posté par farib . Évalué à 3.
Pas de probleme !
Ton ecran HDTV HDCP affichera un message du genre "Unable to authentify HDCP Secure Connection With VideoSource.
[^] # Re: Pour ATI c'est perdu
Posté par mickabouille . Évalué à 2.
[^] # Re: Pour ATI c'est perdu
Posté par Croconux . Évalué à 3.
Euh... ce n'est pas comme ça que ça marche. Ce n'est pas l'écran qui refuse de lire du contenu non HDCP (heureusement sinon on ne pourrait même pas regarder la télé ou un DVD dessus), c'est le lecteur qui refuse de lire le disque si toute la chaîne en sortie n'est pas sécurisée. Si c'est le lecteur que tu débrides pour sortir un signal en clair tu n'as plus aucune cochonerie sur la ligne.
[^] # Re: Pour ATI c'est perdu
Posté par Julien . Évalué à 0.
Si c'est le cas, je ne vois alors pas le problème des DRMs, tant qu'avec mon linux, je peux sortir un flux HD, par exemple tiré du court métrage "Elephants Dream", et que mon écran le lit en HD sans rechigner.
Si les futurs blue ray et autres hd dvd sont protégés et que je ne peux pas les lire ... Eh bien tant pis, je ne les achèterai pas ... On m'aura prévenu, c'est l'essentiel.
[^] # Re: Pour ATI c'est perdu
Posté par briaeros007 . Évalué à 2.
Et ca change pas le problème : j'achète un écran(il est a moi) mais j'ai le droit de m'en servir que dans les conditions prévu par le constructeur (et pour se faire je dois payer 16 000$ les 10 000 couples de clair chiffré si je veux m'en servir dans ces conditions ! (avec 9 999 couples qui me serviront à rien))
C'est comme si j'achetais une voiture et que le constructeur ne veut pas que j'appuie sur la pedale d'embrayage et de frein, ce qui conduis à l'arret du moteur , ou par défaut a 5* moins de puissance...
[^] # Re: Pour ATI c'est perdu
Posté par Obsidian . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.