(Courriels de diversion: <frottent@tergiversons-salerai.com> <depoitraillee@enjoignit-fermoirs.com> <offenserions@enterreront-remaniements.com> <correspondrait@desarconnent-festoyions.com> <renverra@impetueuse-comprendrais.com> <enorgueillirons@symbolisez-ecorcha.com> <jalonnees@recitait-facultes.com> <moduliez@gondole-reparles.com> <telegraphieraient@profileront-monopolisa.com> <lesait@congolaises-captaient.com> )
Le mercredi 21 juin 2006 22:35, Cyb a écrit : > Alors je le balance ... snip > Je ne vois pas l'intérêt du "tout libre". tu m' en voit désolé pour toi. grosso modo, et sans entrer dans des considérations plus générales comme la pérénité du format et d' un support logiciel toujours possible -> conditions primordiales pour les entreprises (qui ont pas envie de se faire avoir 2 fois), voici un très bref résumé de la problématique blob-driver-proprio : ces drivers discutent avec le kernel au travers d' une api (ou abi mais sans détail donc). C' est en fait cette api que l' on compile quant on dit "compilé le driver nvidia" par exemple... dire cette phrase est un abus de langage parceque le driver lui-même est un blob, donc un binaire et il n est fourni que sous cette forme. On peut facilement voir les problèmes survenir à terme : l' évolution du kernel peut être (pourrait être, il ne le sera jamais) pénalisé si l' équipe kernel décidait de plus accepter ce type de driver. Donc à cause de drivers de ce type, dont les équipes de développement ne peuvent pas avoir accès aux sources, on pourrait se retrouver dans la même situation que windows : un kernel dont le développement est ralenti à cause de tierce partie... avec tout les problèmes qui en découleraient. Enfin, il est évident que la notion de sécurité en prends un sacré coup... ces drivers fonctionnent dans un mode privilégié dans le noyau. (et pour être précis pour ceux de cartes graphiques sont : "tapés" par le user simple, par une appli lancée par lui, puis elle va "taper" Xorg qui lui même va "taper" le noyau au travers d' une interface particulière et qui va donc "taper" le driver, lui en mode privilègié....) Donc Blob-closed-sources, même sur un système linux, ne sont pas compatibles avec une utilisation aux besoins sécurisés. Le point le plus important étant donc de ne pas empêcher le ralentissement du développement du noyau (et donc de corrections de bugs, de failles) à cause d' une pauvre api / abi qui ne veut pas évoluer parceque le constructeur n' arrive plus à suivre le ryhtme.... il est très important, primoridal même, de refuser cette non-option là. ps : j ai la flemme de chercher des références ( c' est peut-être dommage, car je ne cherche pas à te convaincre, simplement à pointer des choses que peut-être tu ne sais pas aujourdhui.) : comme un mail de janvier de Linus, ou encore des articles de Theo sur le sujet ou même des articles de RMS (ou tous tombent d' accord, chose rare. (On peut noter que des constructeurs comme HP font particulièrement attention) bon zou, direction la fete de la zik a+ -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>