[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Non, ce sont des devs. Linux qui ont tenté de changer la licence
On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.
Sauf que c'est exactement l'inverse.
Les développeurs OpenBSD (en particulier Reyk Floeter) ont développé le driver (basé sur un travail initial de Sam Leffler pour FreeBSD), et surtout ce HAL libre par rétro-engenérie.
Certains développeurs linux ont assez longuement fudé sur la légalité de ce HAL libre (arguant qu'il n'aurait pas été rétro-engéniré dans les règles de l'art), jusqu'à ce que le Freedom Law Center se penche sur le cas et publie un communiqué lavant le code de tout soupçon.
Peut de temps après, un développeur du projet ath5k (vaguement soutenu par quelques camarades) a décidé de récupérer tout ce bon code d'OpenBSD, sous licence ISC, de trasher la licence et de coller une GPL à la place. Sûrement histoire de favoriser les échanges cordiales entre projets.
[ Répondre ]
Re: Arg
> Ça fait 3 ans au moins que il dit que tant que launchpad est pas
> indispensable il peut pas ouvrir le code sinon ca fragmenterait.
>
> Le but c'est d'être la plate-forme incontournable et de ne liberer
> que si aucun concurrent ne peut se mettre à l'égal.
Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.
Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.
En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.
Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.
Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.
Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).
Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
[ Répondre ]
Re: Une bataille de perdu mais une expérience de gagnée
> J’ai l'impression que certains dirigeants de cette organisation n'ont rien compris du libre.
> Pour eux ce n'est qu'un composant à bas coût.
Bah, j'ai l'impression qu'ils ont au contraire très bien compris.
Très bien compris que le libre, c'est aussi une large communauté d'ingénieurs hyper qualifiés qu'on peut faire travailler gratos, pendant longtemps, sur un projet contraire à leur convictions. Pour peu qu'on pipote un brin sur les objectifs (ou qu'on reste « discret » suffisamment longtemps concernant les « changements d'objectifs »).
[ Répondre ]
Re: Évitons la caricature
La comparaison est amusante, surtout mise en perspective par ce judicieux commentaire sur slashdot. Bah, et bien Wozniac, comme tant d'autres, s'est fait arnaquer sur la marchandise :
Among the same lines:
According to a report in the Wall Street Journal, Apple boss Steve Jobs offered to equip each of the machines with a gratis copy of Mac OS X.
Seymour Papert, a professor emeritus at MIT and one of the project's founders, said the scheme had refused Jobs' offer on the grounds that Mac OS X is a proprietary system.
Papert told the WSJ: "We declined because it's not open source," adding the $100 laptop creators will only choose an operating system where the source code is open and can be altered.
This is what Steve Wozniac had to say a while ago:
I was on a panel with Nicholas in Seoul this year and admired the fact that he'd turned down an offer from Jobs for the Macintosh OS on the OLPC because it wasn't open sourced. I both donated to the program and also bought the give-one get-one and I do have it.
I wonder how he feels about the project now that they are going to use XP...
[ Répondre ]
Ou « comment mobiliser des bénévoles qualifiés pour votre projet »
Amère impression.
Comme si le « portable qui sera 100% libre, du firmware à l'OS » (et la ré-écriture systématique des logiciels python sur le framework Sugar) était surtout une belle stratégie pour raccoller des centaines de développeurs bénévoles pendant des années, attendre qu'ils aient fait un truc livrable, et annoncer, comme par hasard à la dernière minute, que finalement ce sera du Windows XP.
Combien de développeurs talentueux se seraient donné tant de peine pour contribuer à l'OLPC si on leur avait dit, dès le départ, qu'il s'agissait d'un portable sous WinXP ?
Combien de wikipédiens auraient participé à la selection et au nettoyage d'articles pour les enfants ? Aurions nous fait autant de publicité au projet ?
Negroponte est un fin stratège...
Allons, il faut réveler le projet sous son vrai nom :
- One Licence Per Children
- HOWTO get a thousand ultra qualified IT workers build your Windows commercial project for free
- Comment créer une dépendance technologique chez les moins de 10 ans pauvres
- ...
[ Répondre ]
Re: hum
> t'as dû louper ce lien http://www.gnu.org/philosophy/not-ipr.fr.html
Tout à fait d'accord.
Je saisis l'occasion pour signaler ce joli petit texte de Cory Doctorow, traduit en français par Libé au début du mois, et qui explique aussi pourquoi le terme « propriété intellectuelle » est un abus de langage.
Moins formel que le texte de Stallman, mais plus vivant et plus léger, avec des exemples très parlants (par ex. : ma fille, elle est mienne, mais n'est pas ma propriété), bref, un texte plus adapté pour faire sentir le problème au grand public :
http://www.ecrans.fr/Propriete-intellectuelle-est-un,3502.ht(...)
[ Répondre ]
Astuces OpenSSH : le multiplexage
Bon, ça n'a pas grand chose à voir avec le contenu de la dépêche, mais puis qu'on parle d'astuces OpenSSH...
Depuis la version 4.2, OpenSSH est capable de réduire fortement le temps d'initialisation de la connexion (en éliminant le besoin de re-négociation des algos, ré-authentification, ...), car il permet de multiplexer les connexions vers un même hôte.
Les cas d'utilisations qui bénéficient typiquement de cette fonctionnalité sont ceux qui requiert des re-connexions régulières à une même machine, par exemple pour accéder à un serveur Subersion, ou CVS, ou un distcc, ou ceux qui ont l'habitude de se connecter pour lancer une seule commande à la fois (« ssh user@serveur commande »)...
Le principe est simple : on crée une connexion « maitre » initiale, celle-ci est maintenue en fond et sera réutilisée pour toutes les connexions suivantes vers le même hôte.
En pratique :
1) Placer ceci dans son ~/.ssh/config (ce fichier doit être en mode 0600) :
Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p
2) Ensuite, on crée une socket « maître » utilisée pour le multiplexage (cela crée aussi un processus ssh qui maintient cette socket, en arrière plan) vers monhotedistant:
ssh -fMN monhotedistant
Et voila ! On peut maintenant profiter de nouvelles connexions très rapides. Exemple chez moi :
# Avant la mise en place du multiplexage :
$ time ssh monserveur exit
real 0m0.530s
# Avec le multiplexage :
$ time ssh monserveur exit
real 0m0.018s
Autant dire que les opérations courantes (svn diff, log, up, ...) sur mon dépôt subversion sont beaucoup plus confortables.
Une autre astuce dont il faudrait parler : les dernières versions d'OpenSSH permettent de créer des VPN (utilisant des tunnels sur des interfaces virtuelles tun(4), à la façon d'OpenVPN) de façon très simple et ne nécessitant que OpenSSH. Je suis sûr que ça aurait pu être utilisé pour arriver à des résultats similaires à ce qui est présenté dans la dépêche, mais en n'utilisant qu'OpenSSH.
[ Répondre ]
Re: Plus précisément
Oui, bien entendu. Le but de l'exemple était d'éviter de faire une entrée par utilisateur.
Si on est prêt à faire une entrée dans sshd_config par utilisateur, alors Match User convient aussi bien (dans ce cas, il n'est pas nécessaire que les utilisateurs aient des gid uniques).
[ Répondre ]
Re: Utilité de FTP ?
> Tu oubli FXP dans l'utilité du canal de contrôle.
Et, à part la dimension tartufesque de ftp (et le risque sécurité bien connu de cette fonctionnalité de ftp, la fameuse "FTP bounce attack"), quel est l'intérêt de FXP par rapport à un simple :
scp user1@server1.com:/truc user2@server2.com:/chose ?
[ Répondre ]
Re: Plus précisément
> l'utilisateur se connecte dans le répertoire /var/www/users/son_login mais il apparait comme racine / pour lui.
Non, sftp va se chrooter dans ChrootDir, puis va faire un chdir() dans la home de l'user (telle qu'indiquée dans /etc/passwd, mais relative à la chroot).
Autrement dit, si la home de toto indiquée dans /etc/passwd est "/home/toto", que le ChrootDir indiqué dans sshd_config est est "/chroot", alors sftp :
1- se chrootera dans /chroot
2- puis se déplacera dans /home/toto, relativement à sa chroot (donc en vrai, dans /chroot/home/toto).
3- l'utilisateur toto pourra voir les répertoires contigus à sa home (c'est à dire tout ceux en dessous du répertoire /chroot, y compris /chroot/home/pouet/, s'il existe).
Ce qui me fait penser, au passage et pour compléter la réponse que j'ai donné juste au-dessus, que si on veux garder une arborescence des homes du type /home/user1, /home/user2, alors on doit pouvoir faire :
Match Group sftpusers
ChrootDirectory /home/%u
ForceCommand internal-sftp
Et dans /etc/passwd, indiquer "/" comme path de toutes les homes des utilisateurs qu'on veut chrooter.
[ Répondre ]
Re: Plus précisément
> les autres répertoires, et doit rentrer dans le sien.
Non, au login sftp va placer l'utilisateur directement dans /chroot/$HOME/
> Même si les droits sont mis en place pour qu'il ne puisse pas
> rentrer dans les autres répertoires, il les voit.
Voila une astuce simple décrite sur Undeadly, pour éviter que
les utilisateurs ne voient les autres homes :
1) Modifier l'indication des chemins des répertoires home
dans /etc/passwd pour qu'ils ressemblent à : /user1, /user2, ...
2) Créer cette structure de répertoires :
/chroot/user1/user1
/chroot/user2/user2
3) Puis, dans ssh_config :
Match Group sftpusers
ChrootDirectory /chroot/%u
ForceCommand internal-sftp
Et hop, c'est réglé, l'utilisateur ne voit pas les autres homes, seulement la sienne.
[ Répondre ]
Re: Polémique
> mais je trouve un peu dommage que les autres projets aient enormement moins de publicite en comparaison.
Je me demande si ta remarque est un reproche voilé contre cette dépêche (assimilée à de la « publicité » pour le projet Nouveau) ?
Sinon, même remarque que ci-dessous : si tu estime qu'Intel ne reçoit pas assez de pub, tu peu toujours rédiger une dépêche sur les drivers Intel. Il y a plein de choses à dire, par exemple qu'en ce moment même, la version 2.2.1 de leur pilote est en pre-release (v. 2.2.0.90, déjà très stable, mais à tester d'urgence quand même), qu'il y a du boulot en cours pour améliorer les performances d'EXA sur les i965, que le drm Intel est bien avancé (maintenant, le suspend/resume fonctionne totalement sans recourir à des hacks comme vbetool), ou pour parler de la nouvelle branche pour le refactoring du support XvMC d'Intel (avec en perspective, à la clef, l'accélération de la décompression vidéo), ou pour rendre compte des perspectives des premières expérimentations avec Gallium3d + LLVM ou TTM (expérimentations qui sont d'abord faites, comme le dit cette dépêche, avec un pilote Intel)... Il y a de la matière. Bref, pas assez de pub ? then just do it !
J'en profite au passage pour remercier les rédacteurs de cette dépêche, exceptionnellement claire, solide, passionnante, bien écrite, qui permet de se faire une idée très claire de l'état du pilote, des difficultés rencontrés, des perspectives, et au-delà, de présenter d'excitants outils et méthodes de reverse-engeneering.
[ Répondre ]
Re: Polémique
Bien sûr, il est dommage qu'Intel ne soit pas mieux récompensé pour avoir ouvert ses specs (et écrit des drivers libres, et embauché des développeurs pour travailler sur l'architecture plus générale, au-delà de leur chapelle). Et on commence à constater qu'ils comptent un peu là-dessus, sur le canal #intel-gfx ou sur la liste de diffusion de xorg, lorsque quelqu'un parle d'une fonctionnalité manquante et qu'ils répondent désormais, en substance, des choses comme : « oui, on aimerai le faire, mais on manque un peu de temps ; les specs sont à votre disposition, vous pouvez nous aider ». (cela dit, ces specs sont ouvertes depuis très peu de temps, et on ne devient pas développeur de pilote X11 du jour au lendemain).
Seulement c'est le temps libre des développeurs bénévoles, pas le mien. S'il n'y a pas assez de monde pour encourager les initiatives d'Intel en développant (ou pas assez de monde pour obtenir une proportion de contributeurs externes quantitativement plus importante pour Intel que pour nvidia), hé bien, ma fois, c'est ainsi, et je vois difficilement comment on pourrait reprocher à d'autres développeurs de participer à d'autres projets.
Si vous voulez qu'il y ai deux fois plus de développeurs externes sur le driver Intel que sur le driver nvidia, vous pouvez vous-même participer, ou embaucher une équipe. Mais reprocher aux bénévoles de ne pas donner de leur temps... (ou, déclinaison du même reproche, reprocher à certains d'être trop nombreux à donner du temps à un autre projet ....), c'est une goujaterie.
En résumé : il ne faut pas dire qu'il y a trop de développeurs Nouveau, mais qu'il n'y a pas assez de développeurs bénévoles Intel ; et on n'est pas moralement en droit d'en faire reproche à qui que ce soit d'autre que soi-même.
Incidemment : vous pouvez aider Intel, même si vous n'êtes pas développeur, en participant à leur programme de test (ils ont lancé un appel à l'aide à ce sujet). Voir la section "Getting Involved" sur :
http://www.intellinuxgraphics.org/testing.html
[ Répondre ]
La page de référence pour avoir ces renseignements
Les développeurs de la libata maintiennent une page très claire et précise sur ce sujet, avec tout les détails intéressants : fonctionnalités supportées, qualité du driver et du matériel, problèmes connus, qualité du design du matériel, est-ce que les spécifications sont publiquement dispos ou pas, etc.
Pas toujours très à jour, mais si votre matériel est indiqué comme "très bien supporté", au moins vous pouvez être assuré qu'il l'est depuis un bon moment. En l'occurrence, pour les deux chipsets SILC SATA, le driver était déjà stable et complet lors de la dernière mise à jour de cette page.
Silicon Image 3124
Driver name: sata_sil24
Summary: Full TCQ/NCQ support, with full SATA control including hotplug and PM.
The 3124 is a nice, open design.
Donc ce chipset semble un très bon choix. En revanche les Silicon Image 3112/3114 supportent moins de fonctionnalités (mais ont tout de même un driver fiable). Encore mieux, si ça t'es possible, opte pour un chipset pouvant fonctionner en mode AHCI (les Southbridge Intel récents ont un excellentissime support d'AHCI).
La page en question : http://linux-ata.org/driver-status.html
[ Répondre ]
Re: Ligatures.. et scissions
Merci pour vos précisions et corrections.
Ce ne sont pas vraiment mes affirmations, mais, comme j'ai indiqué (et avec des réserves et demandes de confirmations) celles que j'ai trouvé sur le forum indiqué plus haut (que j'ai trop rapidement corroboré avec le fait que mon FF souligne encore les ligatures (mais il s'agit d'un 2.0.11, il faut que je teste la mise à jour)), et sur le site de Vazkor ( http://perso.latribu.com/rocky2/mydico.html où l'on voit qu'il a fait des mises à jour en janvier et indique que la version intégrée dans FF date d'août 2007 ; le README dans les dictionnaires en téléchargement sur votre site parle de septembre 2007).
Comme quoi, une bonne explication détaillée évite bien des confusions (merci de l'avoir fait ici). Peut-être que ces clarifications méritent de figurer dans votre FAQ (parce que c'est bien la première chose que j'ai lu pour essayer de comprendre où allaient les divers forks, qui fait - et a fait - quoi, ce qui était repris ou rejeté parmi les améliorations des autres dictionnaires, et pourquoi, etc.)
[ Répondre ]
Ligatures.. et scissions
Cette mise à jour est une excellente nouvelle, bien entendu. Sans parler du superbe changement de licence (quoiqu'une licence plus permissive, type MIT, aurait permis l'intégration dans d'autres logiciels importants, comme Vim, certains logiciels de messagerie instantanée, etc.).
Mais à fouiller un peu les liens indiqués dans la dépêche et surtout des les commentaires (le lien sur le forum assiste est très instructif : http://assiste.forum.free.fr/viewtopic.php?t=13797 ...), j'en tire une impression de malaise ou pour le moins de relative anarchie. Il semblerait que l'unification des efforts isolés et la prise en compte commune des divers besoins et améliorations subséquentes dans une démarche fédératrice ne soit pas encore à l'ordre du jour.
Pour ce que j'en ai compris - corrigez-moi si je me trompe - ce travail de mise à jour et correction des dicos a été initié par l'énorme travail de Vazkor. Il semblerait qu'ultérieurement, des contributeurs d'OOo (les personnes autour du site Dicollecte / http://dico.savant.free.fr ) aient repris ce travail à un instant donné (dictionnaires de Vazkor, version d'août 2007 - ils ne semblent pas avoir repris ses travaux ultérieurs, bizarrement), l'aient amputé de nombreux apports (enlevé tout les mots avec ligatures (œ, æ) parce que non supporté par OOo sur certaines vieilles plateformes¹, enlevé ses apports intéressants relatifs au filtrage de mots trompeurs comme « détaller » (très rare) vs. « détaler », etc.), mais aient ajouté d'autres apports intéressants (nouveaux mots importants oubliés, quelques corrections, prénoms français, noms des communes de France de plus de 20 000 habitants, ...). Ils ont aussi noyauté les contributeurs aux dictionnaires divers, et proposent une interface intéressante pour soumettre des suggestions. Pour ce que j'en ai compris, c'est leur version qui est intégrée dans les projets OOo (logique) et Mozilla (Vazkor semble trop peut habitué aux mœurs (mot souligné en rouge !) du LL et trop peut anglophone pour défendre sa version, face à celle de Dicollecte, pour l'intégration dans FF).
En conséquence il semblerait qu'on se retrouve avec des scissions, des forks, des versions différentes des dictionnaires. Parfois pour des raisons techniques louables compréhensibles, voir inévitables, mais ça ne clarifie pas les choses. Il semble qu'on ai des dictionnaires français :
- Scindés en versions plus complète (dicos OOo/Dicollecte : prénoms français, grandes villes de France) ou plus correcte (dicos Vazkor : support des ligatures, nombreuses corrections entre août 2007 et février 2008 non reprises par l'équipe OOo/Dicollecte).
- Scindés en versions « orthographe classique » et « orthographe réformée 1990 » (mais Dicollecte fournis une version fusionnée)
- Scindés en versions Myspell et Hunspell.
- Scindés en versions intégrées dans Firefox/TB et versions intégrées dans OOo (visiblement à peut près similaires)
Espérons que ça se tasse avec le temps (probable : unification atour des dicos Hunspell, fusion des dicos classique+réformée, maintenance par l'équipe Dicollecte seule, ...).
Si j'ai bien compris ce qui se passe, je trouve en particulier fort dommage qu'on se tape partout (sans FF, TB et OOo) un dictionnaire ne supportant pas les ligatures² (comment écrivez-vous « œcuménique », « Lætitia », « et cætera » ? Firefox me souligne les mots en rouge et ne propose pas de correction) à cause d'un bug d'OOo sur certaines plateformes. Dommage aussi que le travail de Vazkor entre août 2007 et fin janvier 2008 soit passé à la trappe, et que Vazkor, usé de ce fait, ait décidé d'abandonner son travail³, il était le plus compétent et le plus bosseur (avec Christophe Pythoud, qui a aussi abandonné il y a 8 ans)...
Au rayon des imperfections techniques, il semblerait aussi que les mots composés (avec un trait d'union, quoi) ne soient pas supportés (au moins dans les versions Myspell des dicos) ; l'apostrophes courbe (typographiquement correcte : ´ au lieu de ') non plus. Et la nouvelle licence est bien mieux (permet l'intégration dans OOo, FF et TB) mais ne permet pas l'intégration dans Vim & al.
¹ Du moins, c'est ce qui est expliqué en bas de cette page : http://assiste.forum.free.fr/viewtopic.php?t=13797&postd(...) . Est-ce co
rrect ? Ou s'agit-il d'un bug de Myspell et d'Hunspell ? Pourtant Vazkor semble avoir réussi à produire un dico avec ligature qui fonctionne sous FF et OOo : http://assiste.forum.free.fr/viewtopic.php?p=107681#107681
² Cf. par exemple ici la motivation du rejet du mot « nœthérienne » : http://dico.savant.free.fr/proposition.php?id=513
³ Voir par exemple son annonce sur son site : http://perso.latribu.com/rocky2/mydico.html . Il continue néanmoins son excellent travail de correction des art
icles de Wikipédia (cf. http://fr.wikipedia.org/wiki/Special:Contributions/Vazkor ).
Voila. Si quelqu'un en sait un peu plus sur les problèmes évoqués et les possibilités de résolution, ce serait chouette de nous en parler.
[ Répondre ]
Re: Complément
> Autres statistiques, à l'échelle mondiale ce coup-ci :
> http://www.w3schools.com/browsers/browsers_os.asp
Ce qui me surprend le plus concernant ces statistiques, c'est le faible écart entre le taux d'utilisation de Linux (environ 3.5 % en 2007) et de Mac OS X (environ 4 %).
J'ai toujours cru que les vendeurs tiers (marchands de matériel, de logiciels, de jeux...) supportaient (mise à disposition des spécifications, écriture de drivers, portage des logiciels) la plateforme d'Apple mais pas Linux parce que ce dernier serait beaucoup moins utilisé, et concernerai donc beaucoup moins de clients. Du moins c'est ce qu'ils disent, en général.
Alors de quatre choses l'une :
1) soit le faible support de Linux est du à un autre problème que les vendeurs tiers préfèrent ne pas indiquer (lequel ? pourquoi ?),
2) soit la différence entre 3.5% et 4% de parts de marché est en fait ultra significative pour eux,
3) soit ces statistiques sur les visiteurs de w3school ne sont pas représentatives des consommateurs en général,
4) soit les vendeurs tiers sont mal informés sur la part de marché réelle de Linux
[ Répondre ]
[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Cette page a été générée par Templeet en 0.1148s (dont 0.0123 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: Le futur ?
Exact, le xorg d'OpenBSD est patché pour révoquer ses privilèges très tôt, et depuis longtemps (mais le - petit - processus root restant continue à accéder à l'espace mémoire global, d'où le machdep.allowaperture sur x86).
Ce que viens de faire David Airlie, si j'ai bien compris, est nouveau : il s'agit d'un X11 avec le DRI etc, qui n'a pas besoin de deviser directement d'un accès direct au périphérique PCI / à l'espace dma, ce travail naturellement noyau étant délégué au TTM. C'est un superbe progrès.
Pour le "Ça concerne le long terme" du journal : peut-être, mais surement pas à cause du modsetting : ce dernier est vraiment en voie d'intégration imminente parrait-il.
[ Répondre ]