clearstream a écrit 451 commentaires

> RDDV a dis plusieurs fois à la tribune que non, diffuser un code source ce n'était pas incompatible avec les articles protégeant les DRM

Mais c'est stupide...
C'est complètement stupide de faire un DRM en libre.

Images, le libre fait sont propre système DRM.
Il y a le lecteur mplayer_drm sous licence GPL qui marche nickel avec.
Puisque mplayer_drm voit le flux non crypté (normal, il l'affiche), je décide d'ajouter l'option -dumpstream_decrypt histoire d'avoir une copie.

Ben c'est interdit car j'ai contourné un système de protection et la version de mplayer_drm que j'ai n'est plus GPL ni même du logiciel libre. C'est simplement un programme interdit.

Je te laisse imaginer le merdier que ça peut être si le libre veut faire un lecteur drm de MS.

> 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é.

Ben avant il y avait MS-DOS, IBM-DOS et DR-DOS (excellent ce dernier). Avec les outils Norton on pouvant remplacer un bureau Windows 3.1 très naze par un bureau sexy et très fonctionnel (plusieurs bureau ala Unix). Il y avait plein d'utiliteurs super-sympas, bien meilleurs que ceux de MS (je n'utilisais quasiment jamais ces derniers). On pouvait remplacer tous les programmes. Il y avait aussi une solutions pour compresser les systèmes de fichier qui marchait très. Il y avait des outils sous DOS fabuleux. Les suites de développement de Borland était que du bonheur aussi bien sous DOS que sous Windows.
Il y avait OS/2 multitache, multiread, vrai 32bits bien avant Windows avec l'interface PM Manager vraiment innovante et leur guide ICU d'interface graphique qui a fait largement école. OS/2 faisait tourner pratiquement toutes les applis DOS et Windows du feu de dieu. Les drivers de Windows pouvait être utilisé sous OS/2. On avait Netscape sous Unix pour surfer et Netscape sous Windows pour surfer. On pouvait utiliser SMB de Novell (plus évolué que celui de MS) sous Windows. Ca bourgonnais dans tous les sens et très peu ou pas de procès.

Puis, la cata, Windows NT est sorti avec un API 32 pour la partie graphique. MS-Office sortait (word/excel/etc étaient groupé). Ca a tué Quattropro et Lotus. Windows a acheté je ne sais plus quelle boite et créé Access 1.3 (moyen). Puis est sorti Access 2.0 et couplé à MS-office ça a fait bien des cadavres. C'était le début des ventes liés PC/Windows/MS-Office. C'etait le début des ventes OEM. Le vendeur du PC faisait la hotline et MS était responsable de rien. Plus tard MS a encore perdu un procès pour abus de position dominante aux USA face aux fabriquants de PC (dont la majorité avait la trouille de parler). L'amende a été ridicule et MS n'a en rien changé ses habitudes. Windows 95 pourtant "design for internet" était un térreau formidable pour les virus. Encore aujourd'hui il faut un anti-virus sur toutes les bécanes. Windows 95 qui était un gros greffon sur un système 16 bits (le MS-DOS) a repris l'API 32 bits de Windows NT pour la partie graphique. Ca leur permettait d'étant le monopole de Windows 95 vers Windows NT. C'est bien vu et tous les journaux spécialisé pronostiquait la mort d'Unix dans les 5 ans à venir. Heureusement ça ne c'est pas produit. MS a fait le nécessaire pour écarter DR-DOS alors qu'avec les specs et de lègères modifications DR-DOS pouvait être utilisé avec Windows 95. DR-DOS en a fait la démontration. MS a perdu un procès contre DR-DOS (caldera) à cause de ça. Mais le coup a été fatal à DR-DOS. La surperbe interface graphique de Norton ne marchait plus et comme MS à "soigneusement" fait les choses en imbriquant tout, Norton n'a pas pu refaire son interface pour Windows 95. MS a sorti double-space et mit stacker (?) au rencard. Stacker a gagné un procès contre MS car MS avait pompé du code de stacker. Le coup a encore été fatal, stacker est mort. IE était indéboullonable et pourtant plus pourri que Netscape. Donc Netscape a perdu des parts de marché. Plus tard MS perdait un contre Netscape pour encore abus de position dominante. Mais trop tard Netscape était mort. MS avec MS-DOS et windows 3.1 a permis l'émergence de boucoup de boite. MS avec Windows 95/NT en a tué la grande majorité. Dans les années 95-98 MS a encore perdu un procès pour abus de position dominante contre l'Europe. L'Europe a infligé une amende ridicule à MS (en gros un simple avertissement). MS a "inventé" la touche "windows". Chaque clavier vendu rapporte à MS. Début Windows 95, MS a "inventé" le logo "design for windows". Chaque programme qui a ce logo paye une taxe à MS. A force de pub par MS, l'éditeur de logiciel est bien obligé de se le farcir ce putain de logo s'il veut être crédible. Avec cette politique monolistique ultra-agressive, les investisseurs ont fait les yeux doux à MS. Le titre des MS a pris des valeurs délirantes. MS croulait (et croule toujours) sous le pognon. A une époque, on comptait 1 millionnaire pour 10 employés chez MS ! Le délire. Maintenant c'est les drivers qui sont exclusivement signé par MS. Encore une taxe supplémentaire.

Aujourd'hui MS a toujours les mêmes méthodes nauséabondes mais en plus il y a les brevets et DRM qui sont la peste du logiciel libre.

> t'as un truc intelligent a dire pour une fois ?

Rien qui te concerne.

Fondamentalement ("by their very nature") c'est incompatible, mais en plus il y a DMCA et EUCD/DADVSI qui interdisent de donner la moindre info sur le fonctionnement interne du DRM. Donc le moindre code libre de DRM est interdit pas la lois. Plus anti-libre que ça, ça ne doit pas être facile.

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.html

Les commentaires de Theo de Raadt [1]
Les commentaires de Theo de Raadt [2]

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 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...

Dès le début MS était pourri ?
Ben ça doit être dans les gènes.

Merci pour l'info.

Quelle horreur !

> write(1,"helloworld\n",11);

Descripteur en dur. De plus on courcircuite le stream stdin qui est déjà ouvert.
Longeur de chaîne non portable. Sur certain système \n fait 2 caractère.
Très error prone. Un #define CHAINE "helloworld\n" et un sizeof(CHAINE) serait aussi rapide à l'excécution.

> _exit(0);

Ne fait pas de flush sur les fflux ouverts (OK, ici ce n'est pas nécessaire, puisque ici on n'a rien écrit sur les streams), atexit() est ignoré.

> "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).

> 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.

Quand on voit le "boom" qu'a crée le PC en terme d'innovation mais aussi économique, on se dit que les politiciens seraient bien avisé de foutre les brevets à la poubelle et pour toujours.

Le PC serait vérouillé par IBM, MS ne serait pas né. Bill Gates l'a reconnu.
MS, une boîte sympathique et innovante au début et maintenant presque un poison.

Et notons aussi que le boom de MS est lié à sa polique d'ouverture à ses débuts. Toutes les specs de MS-DOS et Windows jusqu'à la version 3.x étaient dispos et utilisables. Après MS a tout verrouillé et des tonnes de boîtes ont crevés.

Une version optimisée :

main() {
printf("Hello World\n");
}

J'ai honte.

> 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.

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.

Tu préfères les mac ?

Tu peux toujours acheter un PC en kit et le monter. Ce n'est pas compliqué à faire.
Après il y a le problème des portables.
Puis au début des PC, il n'y avait pas de vente forcée. Ce n'est pas le PC qui a créé la vente forcé, c'est MS et ses accords avec les venteurs de PC.

Afin le PC a été et reste encore une plate-forme assez ouverte où on trouve facilement les specs. D'où un innovation considérable au niveau des périphériques et un nombre d'acteur tout aussi considérable.

Merci le PC et joyeux anniversaire !

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 ?

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,
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.

Et comme bien souvent, ces critiques viennent de "fans" d'OpenBSD qui veulent donner des leçons de sécurité.

> 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.

Juste une question :
Pourquoi ?

La structure de Xorg a été significativement retravaillée ces dernières années.

> la perte du dual screen

Je crois qu'il y a des versions dual screen. A confirmer.

> La realite c'est qu'enormement de brevets sont utilisables par les logiciels proprios

La réalité c'est qu'énormément (toute) d'innovation du libre sont utilisable par les logiciels proprios.

> du fait de la clause de redistribution.

Ce n'est pas du fait de la clause de redistribution, mais car c'est un logiciel libre. Un logiciel libre que tu n'as pas le droit de redistribuer librement n'est à l'évidence pas un logiciel libre.
Mais comme tu es un minitant de MS, tu te refuses à présenter la réalité honnètement. Voir le nombre de commentaire que tu as fait en disant que l'incompatibilité brevet-libre était spécifique à la GPL et ne concernait pas tout le logiciel libre.
A l'évidence tu as menti intentionnellement et tu l'as fait mainte fois ici.

> Moi je regardes la realite.

Mais qu'à travers les lentilles de MS.

La réalité c'est qu'avant les brevets logiciels (qui, quelque soit tes mensonges, a débuté effectivement vers mi-1995 ; si tu n'es pas d'accord, vas éditer wikipedia), il y avait une concurrence loyale entre le libre et le proprio. Il y avait aussi énormément d'innovation, le logiciel proprio prospérait (début fracassant de MS), le libre montait en charge, Internet était un succès fulgurant car non encombré de brevet, etc...
Le proprio pouvait reprendre des innovations du libre et vice-versa. Mais il fallait recoder les fonctionnalités car le droit d'auteur s'applique. Une concurrence loyale et saine.

Maintenant il y a les brevets. Les innovations du proprio sont exclusivement pour le proprio et les innovations du libre sont pour le libre et le proprio.
On a *maintenant* un contexte qui crée de façon évidente une concurrence déloyale.

La réalité, c'est quel choix de société on fait. Le choix d'aller toujours dans le sens des grosses boîtes qui veulent s'arroger un maximum de droits (droits exclusifs des brevets, droits exclusifs d'accès au contenu via DRM (EUCD, DMCA, ...)) ou le choix de laisser une concurrence loyale entre le libre et le proprio. Je préfère ce dernier choix et de loin.

C'est une question politique. Le logiciel libre malgrés ces moyens ridicules en terme de lobbying face aux grosses boîtes est arrivé à se faire entendre sur les brevets par l'Europe. L'affaire n'est pas définitivement gagnée. Mais contrairement à ce que tu propages, les bienfaits de brevets logiciels n'ont pas paru évidents. D'ailleurs le parlement a massivement reconnu que les brevets logiciels étaient néfastes et a rejeté la directive.
Néfaste pour la concurrence entre le libre et le proprio (peut-être pas la première préoccupation du parlement).
Néfaste pour la concurrence entre les grosses boîtes et les PME qui font du proprio.

Mais toi tu continues à dire tranquillement que les brevets logiciels ne créent en rien une concurrence déloyale et qu'il ne faut pas croire ceux qui disent le contraire car ce sont des affabulateurs.

T'es vachement culloté.

> Si ces licences veulent utiliser des brevets, c'est simple, qu'elles changent les termes de redistribution ou ajoutent une clause autorisant la distribution a etre limitee aux gens ayant le droit d'utiliser les brevets inclus.

Bref, il faut faire une licence propriétaire.
Géniale ton idée. Proposes la à la FSF.

> Si ces licences veulent utiliser des brevets, c'est simple, qu'elles changent les termes de redistribution ou ajoutent une clause autorisant la distribution a etre limitee aux gens ayant le droit d'utiliser les brevets inclus.
> Sans ca, elles s'excluent d'elle memes volontairement de l'utilisation des brevets, c'est leur choix.

Si les brevets veulent être utiliser par le logiciel libre, c'est simple, qu'ils changent les termes de l'utilisation ou ajoutent une clause autorisant l'utilisaton par les logiciels libres.
Sans ca, ils s'excluent d'eux memes volontairement de l'utilisation des logiciels libres, c'est leur choix.

> Pas de bol pour toi, il y a deja eu plein de proces a propos de brevets logiciels, aucun proces ne s'est termine en "les brevets logiciels ne sont pas valides", et plusieurs se sont termines avec une victoire du detenteur de brevet.

Je parle de la cours suprême.

> Si les licences libres empechent l'utilisation de brevets dans leur definition, c'est leur probleme, pas le probleme des brevets

Si les brevets empechent l'utilisation des logiciels libres dans leur definition, c'est leur probleme, pas le probleme des logiciels libres.

> mais t'as du mal a comprendre le concept d'assumer ses choix on dirait.

mais t'as du mal a comprendre le concept d'assumer ses choix on dirait.

> Si tu lis bien, tu verras que tu es autorise a ecouter le CD, en faire une copie de sauvegarde, ... mais que tu n'es pas autorise a la jouer en public, ... et que tous les autres droits sont reserves.

C'est exactement ce que stipule la loi. Les éditeurs n'ont pas le droit d'ajouter d'autres restrictions.
Mais tu vas être content, avec DADVSI, les éditeurs pourront mettre quasiment ce qu'ils veulent.

> Faut croire que tu lis jamais le texte en petit caracteres, mauvaise idee.

Faut croire que tu ne connais pas loi.

> T'ecris du code libre, mais qui repond aux criteres, c'est pourtant pas complique a comprendre.

C'est celui qui fait DRM qui fixe les specs de mplayer.
Bref, un programme pas libre avec du code libre (assez bizarre comme notion).
Merci de ta démonstration qui prouve que TCPA/DRM c'est mauvais pour le libre.

Les specs :
http://www.intel.com/design/chipsets/datashts/313053.htm
400 pages.

> mais de TOUT les echo que j'en ai eu leur kde est LOIN derriére celui d'autres distribution

C'est quasiment toujours la dernière version de KDE. Mais c'est vrai que KDE n'est pas dans les priorités de Fedora qui préfère investir dans Gnome.
Je comprend qu'un utilisateur de KDE ne prenne pas Fedora.

Je ne crois pas.
L'annonce d'AMD a moins d'un mois. Puis Intel participe depuis longtemp à xorg massivement (surtout comparé aux autres).