Anglicisme

• [^]Re: Anglouse

  Posté par GhZaaark3 () le 15/05/2006 à 17:22. (lien). Évalué à 7.

  Et "refactoring" par "refonte", ce n'est pas une traduction littérale mais l'idée ressort mieux.

  --
  moué...

  • [^]Re: Anglouse

    Posté par Mounir (page perso, ) le 17/05/2006 à 09:55. (lien). Évalué à 0.

    Littéralement, je pense que ce serait refabrication.

    --
    Ce n'est pas sur linux...

petites corrections par rapport au journal

• [^]Re: petites corrections par rapport au journal

  Posté par tuiu pol (Jabber id, ) le 15/05/2006 à 15:52. (lien). Évalué à 10.

  Merci.
  
  Au passage, quand tu as des info intéresantes comme celle-ci sous le coude et assez de courage pour rédiger une dépêche correcte tu devrais directement la proposer en dépêche plutôt que d'en faire un journal.

  • [^]Re: petites corrections par rapport au journal

    Posté par herodiade () le 15/05/2006 à 17:12. (lien). Évalué à 10.

    Je ne me suis pas senti assez à l'aise pour faire une dépêche (le sujet est ardu et m'échappe largement).
    
    Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.
    
    En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.
    
    Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).
    
    Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.
    
    Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...
    
    Voilou.
    
    Un peu de doc complémentaire:
    Les récentes failles sécu d'x.org:
    http://wiki.x.org/wiki/SecurityPage
    L'implémentation des securelevel(7) sous OpenBSD:
    http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel
    SELinux:
    http://en.wikipedia.org/wiki/Security-Enhanced_Linux

    • [^]Re: petites corrections par rapport au journal

      Posté par GhZaaark3 () le 15/05/2006 à 17:34. (lien). Évalué à 1.

      C'est énorme en tout cas, et ne rien faire pour ne pas casser la compatibilité avec des pilotes proprios et bien la preuve qu'on est résolu à ne faire que des concessions et ne jamais s'imposer.
      Après tout, que les distros qui ne veulent pas suivre le pas, ne le fassent pas mais qu'on empêche nullement les correction par peur de voir sa popularité chuter.
      
      Ou alors est-ce une fausse excuse de la part de X.org, ils n'ont peut-être pas pour l'heure, les ressources nécessaires pour ou l'envie de s'atteler à un si gros morceau.
      
      Encore une fois, un apport non négligeable d'OpenBSD qui se voit refuser. Absurdité

      --
      moué...

    • [^]Re: petites corrections par rapport au journal

      Posté par tontonflingueur () le 16/05/2006 à 07:44. (lien). Évalué à 6.

      Je peux essayer de reformuler ? parce que j'aimerais bien comprendre quelle conséquence cette histoire a pour nous autres pauvres utilisateurs. Vous me dites si c'est bien ça ...
      
      Ce que l'on savait déjà :
      
      Le serveur X tourne en tant que root, parce qu'il a besoin d'un accès bas niveau au matériel . Le code du serveur X est très compliqué - plusieurs millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.
      
      Ce qui est nouveau :
      
      Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques. Et bien l'article prouve que ces techniques sont inopérantes dans le cas du serveur X sur les processeurs Pentium, parce que X utilise un mode particulier appelé "mode SMM". En exploitant une faille dans le code du serveur X, il est possible d'exécuter du code dans ce mode. On peut alors contourner toutes les protections supplémentaires apportées par SELinux, et permet aussi de sortir d'une machine virtuelle Xen.
      
      C'est bien ça ? J'ai bon ?

      • [^]Re: petites corrections par rapport au journal

        Posté par Raphaël Gertz (Jabber id, page perso, ) le 16/05/2006 à 09:21. (lien). Évalué à 4.

        En fait il y a deux "proof of concept" (exemple d'exploits).
        
        L'un utilise le mode SMM pour viander toutes les protections du noyaux et pouvoir obtenir les droits niveau noyau.
        
        Pour ceci, l'attaquant a besoin d'obtenir les droits de déclancher une intéruptions SMI pour passer en mode SMM et de pouvoir écrire le code qui va bien, là où il faut pour pouvoir exécuter ce code en mode protégé (le noyau n'y voyant rien du tout).
        
        Concrètement, tu diffuse un module X proprio (genre NVIDIA corrompu), ton root l'installe.
        Ton code modifié va ouvrir une ouverture d'accès direct a la mémoire vidéo légèrement modifié pour écrire dans la partie de mémoire que le mode SMM peut exécuter.
        Après il se débrouille pour lancer une intéruption SMI et paf il charge un module qui lui donne un full accès niveau noyau.
        
        Le cas concret est un de tes utilisateurs XEN se fait trouer et le pirate veux devenir calife a la place du calife...
        
        Pour cette faille il est possible de se protéger en posant certains flags qui vont bien pour interdire le lancement de cette instruction SMI.
        
        Sinon y avais un second hack, mais j'ai déjà oublié...
        
        Enfin la seule solution pour corriger ça serait d'avoir du code "sûr" en mode noyau (avec une whiteliste des fonctions/registres autorisées) et lasser le code useland en ring3 (tournant sous nobody par exemple).
        
        Mais pour ça il faudrait que les fabricants de cartes graphiques qui payent ces même développeurs se décident a libérer les specs de leurs cartes :'(

        --
        site perso : http://rapsys.free.fr/

      • [^]Re: petites corrections par rapport au journal

        Posté par herodiade () le 16/05/2006 à 09:35. (lien). Évalué à 7.

        millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.
        
        Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)
        
        Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.
        
        En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
        Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
        La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.
        
        D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).
        
        et permet aussi de sortir d'une machine virtuelle Xen.
        
        Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.

        • [^]Re: petites corrections par rapport au journal

          Posté par Raphaël Gertz (Jabber id, page perso, ) le 16/05/2006 à 10:23. (lien). Évalué à 3.

          Et des solutions comme kqemu ?
          qui exécute du code directement au niveau hard sur les dernières version ?

          --
          site perso : http://rapsys.free.fr/

    • [^]Re: petites corrections par rapport au journal

      Posté par Markov () le 16/05/2006 à 09:17. (lien). Évalué à 10.

      Xorg (XFree86) est vieux, très vieux. Il y a quelques années peux de systèmes d'exploitation offraient une interface intéressante pour accéder aux BUS PCI et aux matériel. A l'époque XFree86 a donc développer ses propres routines d'accés aux bus (PCI, ISA, ...) et ses drivers. Mais pour ne pas reécrire 50 fois la même chose les drivers ont étés réalisés en user mode (pas besoin d'écrire un driver pour chaque OS et X tourne sur bcp d'OS (solaris, bsd, vm, linux, ...)).
      
      Les dévelopeurs d'Xorg ont bien conscience qu'aujourd'hui ce schéma posse problème. Ils réflechissent à comment évoluer vers un système plus sein, et ce bien avant la publication de Loic. Seulement l'impératif pour les développeurs c'est de ne pas tout casser du jour au lendemain mais de progresser petit à petit.
      
      Par exemple actuellement bcp de développement porte sur l'utilisation du librairie générique d'accés aux bus pci (agp, pcie, ...) qui utiliserait le noyau (bsd, solaris, linux, ...).
      
      Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).
      
      Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".
      
      Nota bene: DRM c'est pas pour Digital Right Management mais pour Direct Rendering Manager
      
      Voila, il ne faut donc pas cracher sur les développeurs d'Xorg (c'est pas gentil ;)) de plus très peux d'entre eux travaillent activement sur Xgl ou AIGLX, la grande majoritée s'occupe de retravailler Xorg afin de corriger les bugs de conceptions et de repartir sur des bases solides (XCB, Xinput, libpci, ...).

      • [^]Re: petites corrections par rapport au journal

        Posté par Pierre Jarillon (page perso, ) le 16/05/2006 à 09:59. (lien). Évalué à 10.

        comment évoluer vers un système plus sein,

        
        Un système plus sain, car il y a des failles au sein du programme.
        Saint Xorg, protégez-nous ! ;-)

        • [^]Re: petites corrections par rapport au journal

          Posté par Markov () le 16/05/2006 à 11:05. (lien). Évalué à 4.

          Argh décidement l'orthographe sera toujours mon pire ennemi :)
          
          Sinon petite précision supplémentaire (je viens d'y penser après un petit tour sous gdb ^^) il est bcp plus facile de faire du "reverse engineering" (j'aime pas trop l'expression francaise :d) d'un driver en user mode qu'un driver dans le noyau.
          
          Je pense notament à la lecture des registres (mmio) ou encore au "man in the middle" (bcp plus dure mais tellement plus instructif).
          
          Quand on voit que le seul constructeur à fournir ses spécifications compléte est intel, on ne peut que penser que le reverse engineering est nécessaire. Enfin c'est mon opinion (j'aime pas les blobs binaires dans le noyau >->)

      • [^]Re: petites corrections par rapport au journal

        Posté par tinou () le 16/05/2006 à 12:01. (lien). Évalué à 2.

        Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).
        
        Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".
        
        Tant qu'on parle de sécurité et de code "propre", je voudrais en profiter pour poser une question, moi qui ne suis même pas développeur: Le concept même de l'architecture DRM ne pose-t'il pas un problème de sécurité ? A part les performances, que reproche-t'on à Utah-GLX (dont j'ai cru comprendre que le code fonctionne intégralement en user-mode) ?

        --
        Tinou

        • [^]Re: petites corrections par rapport au journal

          Posté par Markov () le 16/05/2006 à 12:30. (lien). Évalué à 3.

          Je suis trop jeune pour connaitre les raisons qui ont poussées à abandonner le projet Utah-GLX. Il me semble néanmoins (j'ai une connaissance très limité d'utah dc pardonnez mes erreurs) que le problème été justement la sécurité.
          
          Le module DRM du noyau est vraiment minimaliste pour chaque carte video. Il "scan" les packets de command qui pourrait être dangereux, grosso modo tous les packets qui concernent le transfert de donnée entre la CG et la ram ou la ram et la CG. Il vérifie donc que le processus qui envoit les commandes à le droit d'accéder à la plage d'addresse spécifier. Pour le reste le DRM se contente de faire un bete copier coller (pas exactement ca) des commandes vers la carte graphiques.
          
          Il me semble, mais je peux me tromper, que le meilleur endroit pour faire ce genre de controle c'est dans le noyau. C'est pourquoi utah présentait un modèle 'moins secure'.
          
          Il existe un document qui traite de cela:
          http://dri.sourceforge.net/doc/security_low_level.html
          
          De plus un thread viens de réapparaitre sur la mailing list d'xorg:
          http://lists.freedesktop.org/archives/xorg/2006-May/015368.h(...)
          
          Voir notamment les interventions de Dave Airlie et d'Alan Cox
          http://lists.freedesktop.org/archives/xorg/2006-May/015369.h(...)
          http://lists.freedesktop.org/archives/xorg/2006-May/015377.h(...)

          • [^]Re: petites corrections par rapport au journal

            Posté par Guillaume_T () le 18/05/2006 à 17:42. (lien). Évalué à 3.

            Intervention d'Alan Cox :
            1. "X server *REQUIRES* access to the raw hardware"
            Well actually it doesn't. Whether you bitbang hardware, use a kernel
            provided interface for the card or just some kind of mediated hardware
            interface (eg one that allows only the relevant ports to be accessed) is
            entirely a matter for the driver. In the Linux case you will find all of
            the variants
            
            D'après lui X n'accède pas directement au matériel, il est bien placé pour le savoir non?
            Soit je comprends pas bien, soit cela remet en cause la base sur laquelle se fondent ces fameuses failles.
            Si SElinux est fait pour surveiller ce qui se passe dans le noyau, je ne vois pas comment cela peut lui échapper
            Dave Airlie est assez ironique/vexé, en pretextant qu'on ne va pas accuser le noyau pour toutes les failles potentielles, nombreuses, de X...

    • [^]Re: petites corrections par rapport au journal

      Posté par Matthieu C () le 16/05/2006 à 17:29. (lien). Évalué à 1.

      Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel.
      
      Pas forcement : man fbdev
      
      The fbdev driver supports all hardware where a framebuffer driver is
      available. fbdev uses the os-specific submodule fbdevhw(4) to talk to
      the kernel device driver. Currently a fbdevhw module is available for
      linux.
      

      • [^]Re: petites corrections par rapport au journal

        Posté par Markov () le 16/05/2006 à 19:42. (lien). Évalué à 3.

        Toute personne saine (j'ai bon pour l'orthographe ? ;)) d'esprit n'utiliserait pas fbdev quand une acceleration et disponible et encore une fois ici seul linux (a ma connaissance et d'après man fbdev) posséde un module fbdevhw.
        
        Enfin l'interface définit par fbdev me semble trop minimaliste pour tirer profit des cartes graphiques d'aujourd'hui. Mais la solution qui me semble la plus adapter pour régler ce problème est bien celle d'un module noyau pour chaque carte graphique. Ce module s'occupant des tâches sensible et pénalisant le moins possible l'accés à la carte graphique et à ses fonctionalités. Une grande partie du driver de la carte resterait néanmoins en user mode (facilitant la programmation et aussi le portage sur différent OS).
        
        Néanmons cette solution ne me semble pas réalisable dans un avenir proche aux vues de la pluralitées des systèmes supportés par Xorg.

xegl ?

• [^]Re: xegl ?

  Posté par patrick32 () le 15/05/2006 à 22:19. (lien). Évalué à 2.

  http://www.freedesktop.org/wiki/Xegl
  http://forum.hardware.fr/hardwarefr/OSAlternatifs/Nouvelle-i(...)

  • [+] [^]Re: xegl ?

    Posté par Olivier Abad () le 16/05/2006 à 08:28. (lien). Évalué à -5.

    Et aussi :
    http://abu.cnam.fr/DICO/excent/index.html
    http://members.aol.com/michaemann/jgmain.html

• [^]Re: xegl ?

  Posté par Markov () le 16/05/2006 à 11:13. (lien). Évalué à 4.

  Normalement Xegl devrait résoudre se problème car les parties critiques de la programmation de la carte video auront lieux dans un module du noyau (DRM) qui vérifiera que les opérations qu'on lui demande ne pose pas de problème. Cependant comme l'implémentation d'Xegl est loin d'être terminé, actuellement on ne peut pas évaluer sa robustesse (point de vue sécu).
  
  Cependant comme je le disais dans un poste plus haut 99% des développeurs d'Xorg s'occupent d'autre chose qu'Xegl car pour le moment Xegl ne pourrait fonctionner que sur linux ou freebsd et donc ce n'est pas une solution envisageable à cour terme car Xorg supporte aussi solaris, openbsd, netbsd et d'autres OS.
  
  Donc pas d'accélération du passage à Xegl. De plus des OS comme OpenBSD n'accepteront certainement que des drivers open source pour les cartes graphiques (ca c'est bien :)).

[+] accès direct = DRI ?

• [^]Re: accès direct = DRI ?

  Posté par kolter (page perso, ) le 16/05/2006 à 07:12. (lien). Évalué à 0.

  Et pis si vous compilez pas vos kernels vous avez des ptits zizis

  
  
  en fait pas tout fait, c'est ceux qui savent se servir de leur zizi qui utilisent des distribs avec un kernel correctement compilé et des outils qui permettent de compiler des modules simplement (m-a) !
  
  --> []
  
  M.

  --
  eucd.info : sauvons le droit d'auteur !!!

  • [+] [^]Re: accès direct = DRI ?

    Posté par pankkake (Jabber id, page perso, ) le 19/05/2006 à 15:10. (lien). Évalué à -1.

    C'était pour rigoler, hein.

Patch des bootloaders

• [^]Re: Patch des bootloaders

  Posté par Matthieu C () le 16/05/2006 à 17:26. (lien). Évalué à 6.

  Parce que le code pour le faire est différent en fonction du chipset...
  De plus, c'est pas dit que tout les chipsets fournissent les spec pour le faire...

x.org = mal conçu et a besoin de programmeurs et d'idées !

• [+] [^]la meilleure solution ? Abandonner X et X.org et créer mieux !

  Posté par cbon linux (page perso, ) le 16/05/2006 à 16:58. (lien). Évalué à -1.

  Encore mieux : abandonner X et X.org etc.
  
  X est vieux et très mal fait.
  
  Il est temps de passer à quelque chose de mieux, de neuf.
  Refaire tout ça from scratch.
  
  Peut-être même inclure un serveur graphique basique mais universel dans le noyau ?

  --
  blog

  • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

    Posté par Didier Raboud (Jabber id, page perso, ) le 16/05/2006 à 21:04. (lien). Évalué à 3.

    Qui a [les c***|les testicules|le courage] de refaire un X de zéro ? On l'appelerait Y. Non ?
    
    Bref. Bonne idée [1], en tout cas autant que le Hurd (sur lequel Y devra fonctionner), mais ça va souffrir du même problème que le Hurd : peu de développeurs pour une très bonne idée, donc temps de développement très long, donc désintérêt des communautés.
    
    Dommage.
    
    Conclusion, il faut une très grosse boîte derrière ça qui finance beaucoup de développeurs pour un résultat concurrentiel dans les 2-3 ans.
    
    J'ai bon ?
    
    [1] et je le pense sérieusement.

    • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

      Posté par ptitlouis () le 16/05/2006 à 21:25. (lien). Évalué à 1.

      Il me semble que Y existe déjà, mais je n'ai pas pu retrouver de trace sur google :/

      • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

        Posté par ondex () le 16/05/2006 à 22:00. (lien). Évalué à 5.

        http://www.y-windows.org/
        
        Il y a un peu de vie sur la Mailing list mais je ne sais pas du tout où en est le projet.

        • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

          Posté par Bertrand Jacquin (Jabber id, page perso, ) le 16/05/2006 à 22:13. (lien). Évalué à 4.

          Oui, le projet étant un peu mort, il a été forker, pour donner vie a dsY.
          
          http://en.wikipedia.org/wiki/Y_Window_System
          http://sourceforge.net/projects/dsywindows/
          
          
          Salut a toi Romain ;o)
          
          
          
          XCB est sur le point de remplacer la Xlib.
          
          http://xcb.freedesktop.org/wiki/
          http://bugs.gentoo.org/show_bug.cgi?id=93582
          http://lists.freedesktop.org/archives/xorg/2006-April/015073(...)
          

    • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

      Posté par Markov () le 16/05/2006 à 21:54. (lien). Évalué à 4.

      Décidement je n'arrête pas de défendre Xorg (je vais avoir droit à t-shirt non ? ;)). Le protocol X11 me semble vraiment quelques choses de très robuste et bien conçue (avec quelques points noir).
      
      Ce protocole à aujourd'hui une place de choix dans l'industrie. Il me semble donc inutile de vouloir tout changer en abandonnant un protocol qui a plus que fait ses preuves. On passera un jour au protocol X12 (à cause de certaines limites d'X11).
      
      Le problème ici présenté viens plutot de l'architecture x86 et de l'implémentation des drivers dans le server X (implémentation qui fait aujourd'hui l'object de nombreux travaux voir par exemple la présentation d'Egbert Eich au FOSDEM).
      
      Pour toute personne désirant approfondir ses connaissances d'X je conseille de lire l'article de wikipedia ainsi que les liens fournit dans celui-ci.
      
      http://en.wikipedia.org/wiki/X_Window_System

      • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

        Posté par cbon linux (page perso, ) le 16/05/2006 à 23:31. (lien). Évalué à 1.

        Je comprend pas là :
        X n'est pas "hardware independant" ?
        
        X ne vient pas du MIT ? (ok ils ont bossé pour Sun, HP, IBM, Digital mais c'est pas l'indusrie qui a fait la recherche, c'est des génies de la fac :-) ).
        
        Voilà de quoi lire :
        http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast(...)
        http://www.std.org/~msm/common/protocol.pdf

        --
        blog

        • [^]Re: la meilleure solution ? Abandonner X et X.org et créer mieux !

          Posté par Markov () le 17/05/2006 à 10:00. (lien). Évalué à 2.

          Merci de donner ses liens, j'avais la flemme de les retrouver :) Juste un petit commentaire sur x-window disaster de nombreux problèmes présentés sont aujourd'hui réglés (ne pas oublier que cela à été écrit aux début des années 90 et 10 ans en informatique c'est une éternité :))
          
          Enfin en ce qui concerne le rendu type postscript, cairo commence à s'imposer, sans pour autant interdire l'existence de programmes qui voudraient controler le rendu au pixel près.
          
          Le deuxième lien est une critique bcp plus constructive de X.

Quelle distribution est sécurisée ?