Articles précédents : Logiciel
- [14] Sortie de Oreon 1.3
- [10] KDE 3.5.4 débarque
- [8] Sortie de Sylpheed-Claws 2.4.0
- [7] Wapiti, un scanneur de vulnérabilités web
- [36] Sortie de PhpCompta 2.0.0
- [13] Sortie de TPLN Template Processor 2.7
- [13] Maarch un logiciel libre dédié à l'archivage de documents (GED)
- [15] Sortie de subtitleeditor 0.9
- [33] qRFCview : un petit logiciel libre sympa pour lire les RFC
- [51] OpenOffice.org dans la chaleur de l'été
Liens connexes
- Annonce de la mise à disposition de pilotes libres (640 hits)
- Article sur Slashdot (238 hits)
- Annonce du rachat d'ATI par AMD sur LinuxFR (journal) (732 hits)
- IntelLinuxGraphics.org (510 hits)
- Licences (148 hits)
- Téléchargements (434 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Intel libère ses pilotes graphiques
Posté par jean-philippe gaulier (page perso, ). Modéré le 10 août 2006.
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...
![[en]](../../../images/en.png)
Annonce de la mise à disposition de pilotes libres (640 hits)-
Article sur Slashdot (238 hits)
![[fr]](../../../images/fr.png)
Annonce du rachat d'ATI par AMD sur LinuxFR (journal) (732 hits)-
IntelLinuxGraphics.org (510 hits)
-
Licences (148 hits)
-
Téléchargements (434 hits)
> Lire les commentaires (119 commentaires, moyenne: 3,2).
Les bonnes habitudes perdurent...
C'est tout de même bien d'avoir tout de même un fabriquant de processeurs 3d qui fournisse une implémentation libre de son pilote.
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 () le 10/08/2006 à 11:30. (lien). Évalué à 10.D'autant plus qu'Intel, et ça on y pense pas souvent, est quand même le premier fabriquant de chipsets graphiques (grâce aux cartes mères) devant NVidia et ATI.
-
[^]Re: Les bonnes habitudes perdurent...
Posté par mansuetus (page perso, ) le 10/08/2006 à 11:59. (lien). Évalué à 8.Malgré mon karma négatif, je tente le commentaire !
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 (page perso, ) le 10/08/2006 à 12:33. (lien). Évalué à 4.Je pense que la dernière carte graphique Intel était la i740. La bestiole était pas si mal que ça à l'époque mais elle s'était fait ratiboiser par les concurrents de l'époque (3DFX, nVidia et ATI). Du coup Intel avait jeté l'éponge à l'époque.
-
[^]Re: Les bonnes habitudes perdurent...
Posté par Francois B () le 10/08/2006 à 14:29. (lien). Évalué à 5.Je pense que la dernière carte graphique Intel était la i740. La bestiole était pas si mal que ça à l'époque mais elle s'était fait ratiboiser par les concurrents de l'époque (3DFX, nVidia et ATI). Du coup Intel avait jeté l'éponge à l'époque.
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 (Jabber id, ) le 10/08/2006 à 19:22. (lien). Évalué à 6.En 1997, nVidia sortait déjà la Riva 128. La Riva TNT est arrivée en 1998, et ça commençait à dépoter, même si le leader restait 3DFX.
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 () le 10/08/2006 à 21:57. (lien). Évalué à 3.C'est exact. La première et dernière carte graphique AGP d'Intel par ailleurs. Elle est sortie en 1998, quelques semaines avant que nVIDIA ne débarque avec sa TNT et n'écrase toute concurrence sur le segment des joueurs pour les 4 années à venir. Depuis, on ne trouve que des puces aux performances particulièrement médiocres intégrées aux chipsets. Ca suffit largement pour un usage bureautique voire multimédia, mais c'est à oublier totalement si on veut jouer avec.
-
-
-
OpenGraphics ?
Quid de OpenGraphics ?
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 ?
-
[^]Re: OpenGraphics ?
-
[^]Re: OpenGraphics ?
Posté par ragoutoutou () le 10/08/2006 à 11:52. (lien). Évalué à 10.Quid de OpenGraphics ?
ça n'impactera sans doutes pas ou peu son développement, la philosophie de ce projet étant tout de même son principal pillier.
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...
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 () le 10/08/2006 à 12:06. (lien). Évalué à 4.C'est un risque, mais ce projet OpenGraphics va au delà de simple pilotes libres, à ce que j'ai pu lire puis en même temps, il n'est pas destiné pour le marché des portables.
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 (page perso, ) le 10/08/2006 à 13:50. (lien). Évalué à 3.Je prend ça (ainsi que les rumeurs sur AMD) comme une tres bonne nouvelle pour les effets XGL/Aixgl, car il faut de l'openGL installé par defaut, donc libre pour la plupart des distribs.
Mais les jeux? Je crois pas non... La dedans y'a rien qui va faire changer quoi que ce soit sur les jeux.--
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames-
[^]Re: OpenGraphics ?
Posté par Aurélien Girard () le 10/08/2006 à 13:58. (lien). Évalué à 10.Je prend ça pour une encore meilleure nouvelle : Intel et ATI pensent que le fait de disposer de pilotes libres/open source est un avantage concurentiel !
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 10 ans.
-
[+] [^]Re: OpenGraphics ?
Posté par spaceparanoids () le 12/08/2006 à 00:01. (lien). Évalué à -1.D'accord avec ce commentaire. J'ai bien peur que les jeux vont devoir encore attendre avant de vraiment décoller sous os libre. Mais bon si les specs des cartes sont libres, on va peut-être pouvoir commencer à rattrapper le retard.
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 () le 12/08/2006 à 01:14. (lien). Évalué à 10.Ouais, enfin faut pas charier. DirectX, c'est cool, mais c'est marketing quoi. Quand tu dévelopes un jeu a plusieurs millions de dollars, c'est pas grace à DirectPlay et DirectSound que tu vas économiser 10% de ton budget de dev parce que l'api est supergeniale et que ton jeu online aura des pings reduits de 20%.
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 () le 12/08/2006 à 16:44. (lien). Évalué à 3.Et les jeux playstation? je pense qu'ils s'en sortent très bien sans DirectPlayScool. (héhé et même mieux)
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 () le 12/08/2006 à 22:33. (lien). Évalué à 1.Ouais, enfin faut pas charier. DirectX, c'est cool, mais c'est marketing quoi. Quand tu dévelopes un jeu a plusieurs millions de dollars, c'est pas grace à DirectPlay et DirectSound que tu vas économiser 10% de ton budget de dev parce que l'api est supergeniale et que ton jeu online aura des pings reduits de 20%.
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 () le 14/08/2006 à 13:45. (lien). Évalué à 6.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.
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 () le 14/08/2006 à 15:29. (lien). Évalué à 2.Ben si ca change, ca reduit des couts qui deviennent exorbitants, et plus ils peuvent reduire leurs couts plus ils seront contents.
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 () le 10/08/2006 à 15:12. (lien). Évalué à 9.> ça va enfin décollé
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 () le 11/08/2006 à 09:34. (lien). Évalué à -1.La communauté Open Source à trop "mauvaise presse" pour attirer les différents studio de jeux.
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 (page perso, ) le 11/08/2006 à 10:53. (lien). Évalué à 4.L'imcompatibilité binaire, peut-être aussi. Je me souviens que UT2003 lors de sa sortie marchait sous Mdk 8.2, mais pas sous 9.0.
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).-
[^]Re: OpenGraphics ?
Posté par ragoutoutou () le 11/08/2006 à 11:02. (lien). Évalué à 5.Le gros problème n'est pas une incompatibilité binaire, mais bel et bien que les librairies bougent, et que la compatibilité ascendante n'est pas toujours respectée... Linux reste une cible très mobile, car en évolution constante, un studio de dev de jeux doit être extrèmement agile pour couvrir correctement un tel marché, ce qui constitue un investissement trop grand par rapport aux bénéfices que cela procure.
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 () le 11/08/2006 à 12:22. (lien). Évalué à 8.> La question de la compatibilité binaire doit surement refroidir les rares véléités de proposer un jeu sous Linux.
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 (page perso, ) le 11/08/2006 à 13:18. (lien). Évalué à 6.Pour plus de détail sur ce sujet (pour ceux que ça intéresse), il faut absolument lire /usr/src/linux/Documentation/stable_api_nonsense.txt (enfin si vous avez les sources du noyau dans /usr/src/linux). C'est LE fichier de documentation à lire en premier pour toute personne intéressé par les sources du noyau.
-
[^]Re: OpenGraphics ?
Posté par pierthi () le 11/08/2006 à 17:32. (lien). Évalué à 2.> Par contre, pour tout ce qui est ABI coté programme utilisation Linux est quasiment parfait
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 (Jabber id, ) le 11/08/2006 à 18:01. (lien). Évalué à 1.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.
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 Geoffroy Carrier (Jabber id, page perso, ) le 12/08/2006 à 13:12. (lien). Évalué à 5.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 ;).
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 () le 11/08/2006 à 18:25. (lien). Évalué à 2.Je n ai pas dit que Linux et notament ces librairies étaient sans bug.
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 () le 11/08/2006 à 11:02. (lien). Évalué à 0.Les développeurs et éditeurs ne portent et ne se soucient pas du portage des jeux sous Linux et MacOS X parce que ce n'est pas rentable et qu'il faudrait aussi assurer le support qui va avec. Vu la diversité des distributions Linux, ça peut devenir bordélique ou limitant (genre on ne fait que du Red Hat ou du SuSE).
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 ?
-
[^]Re: OpenGraphics ?
Posté par berti () le 11/08/2006 à 12:15. (lien). Évalué à 1.Le truc qui pose problème avec le fullscreen et deux écrans ?
-
[^]Re: OpenGraphics ?
Posté par Frédéric-Emmanuel Picca () le 11/08/2006 à 12:37. (lien). Évalué à 2.A bon. Moi je joue à xmoto en fullscreen sur un écran pendant que ma copine regarde la TNT (cinergyT2) en fullscreen (gxine) sur l'autre. Le tout avec un laptop ibmT40 et une radeon 7500 Mobility. Ma distribution est une Debian testing.
-
[^]Re: OpenGraphics ?
Posté par berti () le 11/08/2006 à 12:43. (lien). Évalué à 1.Je viens d'essayer xmoto et j'ai bien un problème et c'est comme ça avec tous les programmes SDL en fullscreen. Y'a que la moitié de l'image qui est visible sur un écran et une fenêtre noir sur l'autre.
Carte Nvidia GeForce FX Go5200 sous Ubuntu dapper.-
[^]Re: OpenGraphics ?
Posté par Frédéric-Emmanuel Picca () le 11/08/2006 à 13:06. (lien). Évalué à 2.je ne sais pas mais j'ai l'impression qu'xmoto utilise directement OpenGL pour le graphisme. Est-ce qu'un expert de xmoto pourrait confirmer ?
-
[^]Re: OpenGraphics ?
Posté par ukw (page perso, ) le 11/08/2006 à 15:32. (lien). Évalué à 3.Dans la liste des prérequis :
# 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 ?
Comment se situe le chipset i965 sur le marché ? Il date de quand ? il a quelles perfs et prix comparés aux ATI/NVidia ? Est-il embarqué dans les cartes mères, cartes graphiques et laptops ?
Jabber ID : xmpp:Nyco@jabber.fr
-
[^]Re: i965 ?
Posté par Jux (page perso, ) le 10/08/2006 à 12:26. (lien). Évalué à 8.Si j'ai bien compris les diverses infos glanées sur le net, la carte graphique associée au chipset de carte mère i965 porte le nom de GMA X3000 (une version sans 'X' existe également, moins puissante) et est destinée avant tout aux portables.
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 () le 10/08/2006 à 12:30. (lien). Évalué à 5.Il se situe dans le bas de gamme au niveau de ses performances et a été conçu dans l'optique de répondre à certaines exigeances de vista.
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 () le 10/08/2006 à 18:37. (lien). Évalué à 1.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 :/
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 () le 10/08/2006 à 18:53. (lien). Évalué à 2.> la perte du dual screen
Je crois qu'il y a des versions dual screen. A confirmer.-
[^]Re: i965 ?
Posté par cruciforme () le 10/08/2006 à 18:56. (lien). Évalué à 2.Encore faudrat il trouver la carte mère qui le gère :/. C'est pas trop le marché des carte graphiques intégré le dual screen.
-
-
Une part seulement ?
Si, je cite, "l'open-source peut représenter une part importante des pilotes ATI ", alors ça ne sert à rien. Je sens que sous prétexte de brevets/propriété intellectuelle, AMD/ATI va nous sortir un driver 60% open-source. On va avoir droit a des communiqués/publicités "le module noyau est sous GPL". Chouette, sauf que la libGL, elle, restera fermée.
-
[^]Re: Une part seulement ?
-
[^]Re: Une part seulement ?
Posté par Jean-Philippe (page perso, ) le 11/08/2006 à 05:58. (lien). Évalué à 2.Par "l'open-source peut représenter une part importante des pilotes ATI ", je comprends "on va liberer les drivers des chipsets intégrés pas au top des performances, et on garde fermés ceux de la toute dernière carte graphique qui va devoir exploser nvidia"
Vous affolez ps, y'a anguille sous roche
Ayant déjà bidouillé pour faire tourner ces cartes sous nunux, je sais qu'avant, les contrôleurs videos intel étaient décomposées en 2 chips, l'un embarqué dans le northbridge, et l'autre étant sur la carte mère.
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
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...
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 () le 10/08/2006 à 14:07. (lien). Évalué à 2.Je crois qu'au niveau économie d'énegie, ils sont exemplaires. Peut-être que certains protocoles jusqu'à présent cachés y sont pour quelque chose.
Perso, si AMD et NVidia faisaient de la pub comme ça, je serai plutôt d'accord.--
be a sheep isn't cheap-
[^]Re: Mouaif
Posté par briaeros007 () le 11/08/2006 à 07:41. (lien). Évalué à 2.c'est quand même plus simple de faire de l'économie d'énergie sur un chips bas de gamme que sur le dernier GPU.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Mouaif
Posté par TeXitoi (Jabber id, page perso, ) le 11/08/2006 à 09:09. (lien). Évalué à 1.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.
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 () le 11/08/2006 à 12:06. (lien). Évalué à 6.Le problème, c'est pas le chip, c'est son utilisation.
le problème d'une arme a feu , c'est pas les munitions, c'est son utilisation.
/me sifflote
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.
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.
Mais sous OpenBSD, cette carte marche très bien sans daemon proprio, dc y'a plus qu'a porter un vrai driver sous linux.
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 ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
[^]Re: Mouaif
Posté par ragoutoutou () le 10/08/2006 à 20:47. (lien). Évalué à 4.ton argument est pas mal retournable
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..
Tiens, je pensais que ce serait NVidia qui s'y mettrait en premier, comme je l'ai écrit ici.
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. () le 10/08/2006 à 17:26. (lien). Évalué à 2.Oups, le ici, c'est ça : http://contredon.apinc.org/blog/index.php?2006/07/27/7-bient(...)
-
[^]Re: Futur antérieur..
Posté par sylware () le 10/08/2006 à 22:20. (lien). Évalué à 3.D'ailleurs, l'infrastructure des drivers pour les pilotes de cartes 3D est à faire évoluer. DRI, la fameuse infrastructure, n'est paraît-il pas disociable de X (d'ailleurs je crois qu'on en décourage toute tentative sur le site de DRI). J'ai entendu parler d'une version DirectFB/DRI qui serait indépendante de X, à vérifier.
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 () le 10/08/2006 à 22:50. (lien). Évalué à 3.Juste une question :
Pourquoi ?
La structure de Xorg a été significativement retravaillée ces dernières années.
-
[^]Re: Futur antérieur..
Posté par oops (page perso, ) le 11/08/2006 à 07:36. (lien). Évalué à 3.> J'ai entendu parler d'une version DirectFB/DRI qui serait indépendante de X, à vérifier.
C'est DirectFBGL :
http://www.directfb.org/downloads/Core/README.DirectFBGL
-
[^]Re: Futur antérieur..
Posté par Brice Arnould ( un_brice ) (page perso, ) le 11/08/2006 à 11:21. (lien). Évalué à 0.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).
Déjà, tout le monde n'a pas un moteur de rendu OpenGL, et rien ne prouve qu'OpenGL dure éternellement. En plus, OpenGL a clairement pas été conçu dans cette optique.
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.
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.
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é).--
Respect à RMS.-
[^]Re: Futur antérieur..
Posté par Bruno Ethvignot (page perso, ) le 11/08/2006 à 12:55. (lien). É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 Brice Arnould ( un_brice ) (page perso, ) le 11/08/2006 à 14:11. (lien). Évalué à -1.La plupart de ces cartes 3D dédient 90% de leur silicium au pipeline 3D.
La méduse est constituée de 95% d'eau. Ça serais dommage de pas la boire.
Plus sérieusement, tu confond l'API et les capacité sous jacentes du hardware que l'API exporte.
Apple et Microsoft semblent déjà avoir reçu le message que la 3D est la voie à suivre et ont fait la transition.
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.
Je ne vois pas ce qui pourrait tuer OpenGL
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 ?
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) ?
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).--
Respect à RMS.
-
[^]Re: Futur antérieur..
Posté par clearstream () le 11/08/2006 à 15:30. (lien). Évalué à 5.Je ne suis pas spécialiste en interface graphique.
> http://linux.tlk.fr/traitement-graphique/
Très intéressant.Regardez votre écran, c'est une surface 2D plate, non ?
"surface 2D plate" : joli pléonasme.D'autre part, plusieurs développeurs de X m'ont dit de cesser de parler du paysage concurrentiel. Ils disent que tout ce qu'ils veulent faire c'est rendre X meilleur.
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.Alors que les développeurs de X ne se sentent pas concernés, je suis certain que des cadres de chez Red Hat et Novell ne seront pas d'accord avec cela quand ils commenceront à perdre du chiffre d'affaires à cause d'une interface utilisateur graphique non compétitive.
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.Le noyau Linux contient environ 10 millions de lignes de code qui fonctionnent en root. Le serveur X contient 16 millions de lignes de code dont certaines sont exécutées en root. Si vous recherchez des trous de sécurité, où avez-vous le plus de chance ?
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).Il n'y a aucune raison technique exigeant du serveur X de fonctionner en root.
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(...)
A brief perusal of the paper shows that it describes a way for the *superuser* to circumvent securelevel restrictions. This is interesting,
Et comme bien souvent, ces critiques viennent de "fans" d'OpenBSD qui veulent donner des leçons de sécurité.
but
(a) it describes an attack by a malicious *superuser*, and
(b) it describes an attack by a malicious person who *already* has an
account on the machine under attack.
(a) in particular makes this of more academic than practical concern
-- a malicious superuser has about 6.02e23 different ways to take over
the system, so adding one more is of little interest. This "attack"
is trivially preventable by not allowing malicious persons to become
superuser in the first place, indeed by not giving them logins.-
[^]Re: Futur antérieur..
Posté par clearstream () le 11/08/2006 à 16:54. (lien). Évalué à 2.D'autres choses que j'ai oublié en cliquant trop vite sur "validé".
> http://linux.tlk.fr/traitement-graphique/Que se produit-il si vous installez plusieurs cartes vidéo et exécutez plusieurs utilisateurs localement ? Cela ne fonctionne pas.
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.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.
???D'ailleurs, le serveur X n'est pas précis au pixel non plus.
??? Je doute très fort de cette affirmation. C'est pour le rendu des polices ?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 ?-
[^]Re: Futur antérieur..
Posté par Bruno Ethvignot (page perso, ) le 11/08/2006 à 20:02. (lien). Évalué à 1.Ca marche ! Je l'ai fait (2 claviers, 2 souries, 2 cartes graphiques
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 () le 11/08/2006 à 20:30. (lien). Évalué à 1.> Oui comme l'écrit Jon Smirl voilà un an, des rustines permettent de faire fonctionner le multiutilisateur sous X.
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 (page perso, ) le 11/08/2006 à 17:41. (lien). Évalué à 3.Donc singer Windows est une garantit de succès ?
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 () le 11/08/2006 à 19:42. (lien). Évalué à 2.> 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 ».
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 () le 12/08/2006 à 00:25. (lien). Évalué à 8.A ceci près que dire "il faut être root, donc ça sert à rien" c'est assez imprécis.
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 () le 12/08/2006 à 07:40. (lien). Évalué à 1.Je sens qu'on va s'amuser...
> 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.htmlLes commentaires de Theo de Raadt [1]
Selon 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"
Les commentaires de Theo de Raadt [2]Les développeurs x.org, pour l'essentiel payés par les distributions commerciales, sont-ils trop occupés à coder des environnement 3D ? Ont-ils peur de casser la compatibilité avec les pilotes propriétaires (ATI / nVidia, qui sont maintenant nécessaire pour vendre des distribution commerciales), comme le suppose Theo de Raadt ?
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...Ce qui est certain, c'est que les patches permettant la séparation des privilèges (réduire le nombre de lignes tournant en root dans x.org) développés par OpenBSD n'ont pas été intégrés par l'équipe d'x.org.
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.Quoiqu'il en soit, nous allons certainement garder notre trou dans le X pendant quelques années : visiblement, personne chez x.org n'a décidé de régler ce problème (qui requiert, tout de même, un refactoring complet !).
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.Moralité, mais tout le monde le sait, n'installez pas de serveur X11 sur vos serveurs en production.
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.Ou n'utilisez pas l'architecture i386."
Et élitiste avec ça...-
[^]Re: Futur antérieur..
Posté par djrom () le 12/08/2006 à 10:18. (lien). Évalué à 2.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 ?
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.
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 ?
*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.
Sur un système Linux moderne, ça veux pas forcément dire être root
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.
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.
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.
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.
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 () le 12/08/2006 à 13:31. (lien). Évalué à -2.> et après t'exploite une faille locale qui te permet de devenir root.
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 () le 12/08/2006 à 13:58. (lien). Évalué à 2.
Si pour toi un système donnant 4999 chances sur 5000 de tout péter est sûr, alors t'y comprend rien.
Pfff, t'as moyen de faire sans l'aggressivité ?
Au fait, cdrecord peut s'utiliser sans setuid. C'est comme ça depuis au moins 2 ans.
Est-ce que j'ai dit le contraire ?
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".
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 () le 13/08/2006 à 00:16. (lien). Évalué à -3.> Bon ben trop d'aggressivité pour moi
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
Ati déclare : "Nous aimons nos drivers propriétaires" : http://news.com.com/2061-10791_3-6104655.html
"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 () le 11/08/2006 à 20:37. (lien). Évalué à 3.> "Par ailleur, les composants multimédias qui ont des parties protégé ne peuvent pas , par leur nature, etre libéré"
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 () le 13/08/2006 à 23:27. (lien). Évalué à 2.Mais je n'ai jamais eu de doute, je dis depuis le debut que la definition meme d'un soft libre empeche l'utilisation de code reposant sur des brevets.
-
[^]Re: Pour ATI c'est perdu
Posté par clearstream () le 14/08/2006 à 15:51. (lien). Évalué à 0.> je dis depuis le debut que la definition meme d'un soft libre empeche l'utilisation de code reposant sur des brevets.
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 () le 14/08/2006 à 16:14. (lien). Évalué à 1.>Bonne nouvelle, t'es passé de GPL à "la definition meme d'un soft libre".
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 () le 14/08/2006 à 16:55. (lien). Évalué à 5.De la GPL (qui represente l'enorme majorite des softs libres)
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' ...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Pour ATI c'est perdu
Posté par pasBill pasGates () le 14/08/2006 à 17:26. (lien). Évalué à 1.La BSD par exemple n'a pas ce probleme comme on l'avait deja dit dans un autre thread, donc elle est out. La MIT represente un faible nombre compare a la GPL, tout comme les autres licences.
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 () le 14/08/2006 à 18:11. (lien). Évalué à 4.> La BSD par exemple n'a pas ce probleme
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
Copyleft licenses such as the GNU GPL insist that modified versions of the program must be free software as well. Non-copyleft licenses do not insist on this.
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 () le 14/08/2006 à 17:58. (lien). Évalué à 3.> Tu peux trés bien faire un code libre qui utilise un brevet , ce sont deux choses complètement différentes.
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 () le 15/08/2006 à 10:27. (lien). Évalué à 2.C'est-à-dire pas de restriction d'utilisation par le logiciel libre.
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).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Pour ATI c'est perdu
Posté par clearstream () le 16/08/2006 à 02:33. (lien). É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.
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/BrevetUn brevet est un titre de propriété industrielle qui confère à son titulaire un droit exclusif d'exploitation sur l'invention brevetée
...
Droit
Le droit exclusif d'exploitation est un « droit négatif », interdisant à des tiers d'utiliser, produire, importer ou vendre l'invention couverte par le brevet sans le consentement du titulaire. Ainsi, le brevet n'est pas un « droit positif » qui autoriserait le titulaire à exploiter l'invention, en particulier lorsque celle-ci présente des caractéristiques brevetées par des tiers.
> 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 () le 16/08/2006 à 10:16. (lien). É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 ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Pour ATI c'est perdu
Posté par Vador Dark (Jabber id, ) le 17/08/2006 à 10:18. (lien). Évalué à 2.Et donc, quand tu mattes ton DVD protégé par CSS, c'est "uniquement" pour expérimenter la technologie CSS? Je me demande bien quel juge goberait ça.
-
[^]Re: Pour ATI c'est perdu
Posté par briaeros007 () le 17/08/2006 à 14:16. (lien). Évalué à 2.quand on a vu que certains députés/ministres ont cru (ou au moins dis) que la dadvsi allait protéger l'interopérabilité, ca me choquerais pas plus que ca , avec un bon avocat bien sur.
puis faut bien faire des tests exhaustifs pour être sur que ca marche ;)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
-
[^]Re: Pour ATI c'est perdu
Posté par clearstream () le 14/08/2006 à 17:50. (lien). Évalué à 0.> Incompatible oui, du fait du contenu de la licence.
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 () le 14/08/2006 à 18:57. (lien). Évalué à 3.Et comment tu fais toi qui est si malin pour faire une licence libre qui accèpte les brevets logiciels ?
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 () le 14/08/2006 à 19:57. (lien). Évalué à 2.> Incompatible oui, du fait du contenu de la licence
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.
If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License
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 () le 13/08/2006 à 07:57. (lien). Évalué à 4.Disons que ce n'est pas encore gagné... faut jamais dire jamais...
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 (Jabber id, page perso, ) le 13/08/2006 à 09:56. (lien). Évalué à 4.Et puis le truc c'est si demain il y a une carte intel avec chip graphique pratiquement libre avec pilote pratiquement performant, amd peut se brosser pour garder ses fans chez les geeks libristes si il donne des cartes avec chips graphiques intégrés proprio.
-
[^]Re: Pour ATI c'est perdu
Posté par pasBill pasGates () le 13/08/2006 à 23:31. (lien). Évalué à 3.amd peut se brosser pour garder ses fans chez les geeks libristes si il donne des cartes avec chips graphiques intégrés proprio
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 (Jabber id, page perso, ) le 13/08/2006 à 23:53. (lien). Évalué à 2.Est-ce que les geeks libristes représentent une part si faible de la population ?
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 () le 14/08/2006 à 01:52. (lien). Évalué à 1.Ben Linux sur le desktop c'est quoi ? 3% ? Sur ces 3%, combien sont des libristes 100% qui refusent d'utiliser des drivers non-libre ? 10% ? Ca fait 0.3% du marche...
-
[^]Re: Pour ATI c'est perdu
Posté par Jean-Philippe (page perso, ) le 14/08/2006 à 07:05. (lien). Évalué à 4.Tu fais abstraction de ceux qui utilisent des drivers non libres mais qui choisiraient du libre s'ils en avaient l'occasion. Une bonne partie je pense.
-
[^]Re: Pour ATI c'est perdu
Posté par Vador Dark (Jabber id, ) le 14/08/2006 à 09:40. (lien). Évalué à 1.Oui, mais comme avec les chips graphiques disposant de drivers libres, on n'a pas d'énormes performances, je pense qu'ATI n'a pas trop de soucis à ce faire. On peut espérer que les prochaines générations de chips Intel rattrapent leur retard, mais j'en doute, ce n'est pas trop leur créneau.
-
[^]Re: Pour ATI c'est perdu
Posté par pasBill pasGates () le 14/08/2006 à 10:55. (lien). Évalué à 1.Ben non, ceux la ils n'ont visiblement pas bcp de problemes a utiliser du non-libre, donc je doutes qu'ils vont boycotter quoi que ce soit.
-
[^]Re: Pour ATI c'est perdu
Posté par vrm (page perso, ) le 14/08/2006 à 12:43. (lien). Évalué à 0.j'ai une GeForge un peu vieille qui tourne avec driver proprios, si une carte Intel sort en AGP, j'achete
-
[^]Re: Pour ATI c'est perdu
Posté par pasBill pasGates () le 14/08/2006 à 17:33. (lien). Évalué à 3.Et les milliers de postes Linux en Extramadure, a Munich, ... ils vont aussi acheter une carte graphique Intel parce que les drivers sont maintenant libres ? J'ai comme un doute, pourtant ces desktops la ils comptent bcp pour les 3% de parts de marche. Que des gens isoles le fassent je n'en doute pas un instant, qu'ils aient un impact sur AMD/ATI j'en doute par contre enormement.
-
[^]Re: Pour ATI c'est perdu
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 14/08/2006 à 19:37. (lien). Évalué à 3.Et les milliers de postes Linux en Extramadure, a Munich, ... ils vont aussi acheter une carte graphique Intel parce que les drivers sont maintenant libres ?
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 () le 15/08/2006 à 09:47. (lien). Évalué à 2.[quote]Et les milliers de postes Linux en Extramadure, a Munich, ... ils vont aussi acheter une carte graphique Intel parce que les drivers sont maintenant libres ?[/quote]
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 () le 15/08/2006 à 10:17. (lien). Évalué à 2.Pour les bécanes à chipset graphique intégré,
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 () le 15/08/2006 à 11:10. (lien). Évalué à 1.la plupart des administrations ne font même pas confiance en AMD. Ils sont très frileux. ça a déja été un exploit qu'ils aient pu s'insérer dans le créneau serveurs avec les opterons.
-
[^]Re: Pour ATI c'est perdu
Posté par ragoutoutou () le 15/08/2006 à 11:55. (lien). Évalué à 4.la plupart des administrations ne font même pas confiance en AMD
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 () le 15/08/2006 à 13:09. (lien). Évalué à 1.tu sais, fournisseurs ou pas, ils ont déja du mal à changer de marque de stylo...alors de cpu !
-
[^]Re: Pour ATI c'est perdu
Posté par ragoutoutou () le 15/08/2006 à 14:29. (lien). Évalué à 2.tu sais, le mieux est de vérifier avant de dire n'importe quoi...
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 () le 15/08/2006 à 14:58. (lien). Évalué à 2.tu sais, le mieux est de vérifier avant de dire n'importe quoi...
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 () le 15/08/2006 à 15:42. (lien). Évalué à 3.Me remarque initiale allait par rapport à
et la plupart de ces pc sont équipés d'une carte graphique intel intégrée à la carte mère.
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
tu sais, fournisseurs ou pas, ils ont déja du mal à changer de marque de stylo...alors de cpu !
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 (page perso, ) le 13/08/2006 à 18:54. (lien). Évalué à 1.A noter: la partie macrovision dans le driver intel est justement... proprietaire. Les explications ici:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115536806(...)-
[^]Re: Pour ATI c'est perdu
Posté par clearstream () le 13/08/2006 à 19:09. (lien). Évalué à 1.Oui. Mais mais ça ne sert que si on veut utiliser des programmes propriétaires (DRM, etc). Sinon, ça ne sert à rien sur un système libre.
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 (page perso, ) le 14/08/2006 à 19:31. (lien). Évalué à 2.Note bien que je dis pas le contraire :-)
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 () le 14/08/2006 à 20:00. (lien). Évalué à 2.Ben lire un DVD avec DRM, etc...
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 () le 14/08/2006 à 13:38. (lien). Évalué à 2."In addition, multimedia elements such as content protection must not, by their very nature, be allowed to go open source."
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 () le 14/08/2006 à 15:45. (lien). Évalué à 3.>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" ?
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
-
[^]Re: Pour ATI c'est perdu
Posté par Croconux () le 15/08/2006 à 11:07. (lien). Évalué à 3.Ton ecran HDTV HDCP affichera un message du genre "Unable to authentify HDCP Secure Connection With VideoSource.
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 () le 15/08/2006 à 23:14. (lien). Évalué à 0.J'avais entendu parler d'écrans qui ne diffusaient le contenu qui arrive non crypté qu'avec une résolution plus faible. Est-ce que dans ce cas là, c'est en fait aussi le lecteur qui limite la qualité ?
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 () le 16/08/2006 à 10:23. (lien). Évalué à 2.de tete (mais je peux me gourer) ca dépend du média toussa : ca peut aller d'une baisse de résolution à un joli écran noir .
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...--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
[^]Re: Pour ATI c'est perdu
Cette page a été générée par Templeet en 0.3958s (dont 0.0701 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.