Sous X11 (et XFree), c'est les fonctions de Backing store et de SaveUnder. Peu utilisé voire désactivé car ayant des défault d'implementation. (Il y a un thread a ce propos dans les archives de la mailling list de Render).
Comme d'ab, c'est un problème mineur d'implementation, pas de design.
Attention,
Il faut arrêter de penser que 2D et 3D sont totalement séparées dans nos chip graphiques.
C'etait un peu vrai au tout début lorsque la 3D cablée se cherchait.
Dans nos cartes graphiques actuelles (et un peut moins actuelles) rien ne t'enpèche d'utiliser les fonctions d'alpha blending hors du contexte du pipeline open gl de la partie purement 3D ton driver.
De la même manière, comme tu l'évoque a demi mot (100-90 = 10%), tu as dans ces 10% des cartes capables de faire de l'Alpha sans pour autant avoir de support 3D.
On en revient toujour au même : la qualité du driver qui est le premier point, et le niveau de support accéléré du driver pour la carte considérée. (Rien n'empèche d'avoir un driver d'excélente qualité, mais n'exploitant malheureusement que 60% des fonctionnalités de la carte ...)
C'est devenu la mode en ce moment. Après Bush, la BOD de Xfree86....
Le truc qui me fait gerber dans l'histoire, c'est que cette même équipe qui fout Keith dehors pour des pseudo raisons de non transparence, de manque d'esprit opensource est le noyau dur le plus réac et conservateur qui soit ...
Arretons le débat XFree86 gourmant / XFree86 lent. C'est faux et archi faux. Les principaux problèmes de XFree86 sont :
- une non coopération avec le système sous jacent.
- le manque d'un support kernel correct (ca arrive doucement avec les mutations futures du DRI)
- le manque de drivers 100% corrects
- un immobilisme et un conservatisme dans les possibilités d'évolutions de XFree86 pour corriger ses quelques (gros) défaults d'impléméntations, qui etoufe le projet.
Reportez vous à http://linuxfr.org/2002/10/28/10118.html(...)
J'avais a l'époque beaucoup évoqué les pblm de design de XFree86, le pourquoi du comment et le futur envisageable.
J'avais été assez modéré sur l'atitude de la core team parce que c'est eux qui tirais même lentement le projet vers l'avant mais là, ca a beau être des bêtes, des killers, ils n'en sont pas moins des sales putain de réac conservateurs.
Si, le code de Xfree86 est accessible depuis qques temps en CVS, si les listes sont toutes open depus quelques mois seulement, c'est sous la pression de la communauté opensource et les impératifs dû au projet DRI/DRM beaucoup plus ouvert et dans l'esprit que nous connaissons. C'est en tout cas pas grace à leur adhésion à cet espris qu'il prennent ici pour pretexte pour virer Keith.
Toutes les avancés de Xfree86 4.3 visible pour les utilisateurs à savoir RandR, Fontconfig, XCursor Xr, Render sont des projets et du code menés par Keith.
Dans les dernières discutions sur linux-fb-devel et dri-devel, j'ai cru rêver, l'équipe DRI, les personnes du fb linux, Linus en personne, Alan Cox, tous discutaient de l'intégration et du futur du DRI / FB / XFree. mes rêves les plus fou ( voir toujour http://linuxfr.org/2002/10/28/10118.html(...) ) ont une chance de devenir réalité.
Alors vive Keith, vive un Fork de XFree86.
Quand au pblm de licence. XFree ne DOIT PAS changer de licence. La raison est simple, XFree86 est devenu la référence X11, c'est aujourd'hui l'implémentation de référence du X Consortium. Un fork GPL/LGPL lui ferait perdre cette legitimité aquise en 10 ans de dur travail et qui permet à la comunauté open source de faire évoluer le standard X11 officiellement (et non pas sous forme d'extention spécifiques XFree86).
D'ailleur, je propose un nom à ce fork : XFree
Ben oui, le nom officiel du projet actuel est XFree86 et l'équipe actuelle défend depuis des années ce 86 qui n'a plus de sens aujourd'hui et ce de manière presque intégriste.
Aie aie aie,
Je sens que ca derape alors j'arreterai là.
C++, ben ouais réécrivons tout en C++, le kernel, la libc (plonk), après on ecrira des super outils de la mort qui tu pour profiler systematiquement tout ca étant donné qu'aubout d'un moment, n'étant même plus capable de savoir ce que fait réellement le code, ben faut tracer, analyser, bencher a la methode vodoo, j'ty rajoute un pti buffer de truc par ci et par la sinon mon bastringue fait houatmille millier d'intanciations allocation desalocation secondes et ca ramme, ca bouffe de la ram. puis derière j'ty pond deux trois script magiques pour analyser les sections de code générées pour voir pourquoi mon "hello world" genère un code objet de 20Mo et alloue 100Mo de ram en runtime, pius après je me rend compte que mes trois putains de classes X Y et Z ben c'est caca et je devrai avoir à la place un truc genre V W, mais la je remet pas en cause l'implementation de mes objets, mais l'ensemble de la conception parce que de toute manière je sais plus comment est branlé tout le reste vu qu'il me faudra au moins 3 mois pour retrouver comment mon truc U derive de mon machin T lui même hérité de ..... Bon un pti pointeur bien placé par là et hop le tour et joué et puis dans tout ce merdier bien opaque (c'est la philo du machin, c'est bien ) personne n'y vera que du feu...
Merde, ca rame quand même sur ma machine ben oais, ca s'apelle Mozilla.
Et puis tous les developpeurs windows font du C++ non ? Ben oui, c'est MSVC++ le non du compilo non ?
Quand à Carmack, il a eu le temp de le paufiner son design avant de passer au c++, Doom1 doom2, Quake 1,2,3 bon je lui fait confiance pour passer au c++ maintenant, puis on peut pas, à lui, reprocher le fait qu'il code en ++ "parceque c'est un super language qui resoud même le fons du pblm à ta place". Tu chi de la déclaration, des classes, de l'objet et hop ca marche, sinon ben c'est pas ta faute, c'est le compilo, c'est l'os, ben coment tu gère le truc T et le machin M ? Ha, j'sais pas c'est l'objet O, quel boulet le développeur de O. Par contre le design D, ca personne connais, et le développement incrémental si cher a notre comunauté OpenSource ca marche pas bien avec ++ ? ben c'est que c'est de la merde alors.
Alors bon, c'est sur Mozilla est en ++ et l'histoire nous a montré que du coup il n'avait jamais de trou de sécurité....
A la vue de la pluspart (j'ai pas dit tous .... mais a tout bien réfléchi, presque) tes posts dans cette news, y a deux solutions: Soit ca te fait simplement tripper de foutre la merde et d'exiter les gens avec des propos gratuitements provocateurs et sans intérêts réels (un trollermaster ?), a mois que ce soit dans l'expectative de te recycler dans la socio (nouvelle thèse ?), ou alors on a affaire a qq'un du style des types qui viennent de découvrir l'informatique depuis moins de 2 ans et qui savent tout sans avoir jamais rien fait genre adolescent boutoneu. Vu la date de ta Thèse, je penche plustot pour la première solution.
Sans rancune.
Un vieux con qui pense très sérieusement se recycler très prochainement dans la plomberie/electricité/maconerie.
Pas compliqué, y avait pas de norme a l'époque, juste des concepts et des pratiques courantes....... et des drafts de normes hummpphh...
Quand au code généré, on en parle même pas, de la grosse emulation soft pour les exceptions et j'en passe...
Je ne m'adressais pas a toi en particulier: Pour répondre de manière générale à un peu tous les posts:
Tu remarquera que je n'ai pas critiqué Qmail.
1- Maintenant si tu veur parler perf, faut voir les conditions de test.
Ton Qmail avec une liaison satellite meme a haute vitesse (d'une manière générale, grande bande passante et forte latence), ben il va se vautrer par rapport à un Sendmail.
voir: http://www.cs.helsinki.fi/linux/linux-kernel/2003-09/0002.html(...)
2 - Qmail est un excelent mailer construit sur une base plus saine que sendmail et plus simple car il ne supporte pas tout. cf 1 et mon post precedent. Faut pas me faire dire ce que je n'ai pas dit :-)
3 - Oui et alors ? Sendmail est toujour majoritaire, l'est historiquement parcequ'il était un peut tout seul avant... il y a moins de 10 ans tu demandais à qq'un ce q'était Internet il t'aurait répondu kezako ? Y avait pas beaucoup de personnes non plus avec des serveur mail sous win3.11 ou 3.51 .... Ajoud'hui le reste du parc dans les stats c'est du MS ou de la gateway antivirale...
Qmail est troisième cool. A mon avis dans des stats plus récentes postfix aurra progresse.
4 - Je pensait que c'etait Qmail. Certe.
5 - Combien de bug critiques dans sendmail dans des cas de config ultra tordu "que de toute manière les zautres savent pas faire donc risquent rien...." Bon, cette fois il est plustot balaize mais très objectivement ca arrive si souvent que ca ????
6 - je parlais de l'accès au map alias, mbox, mailserver etc... ou ce que tu voudra, dans du LDAP, SQL etc...
Quand je vois comment c'est fait dans postfix pour le LDAP, plustot que de me faire chier a mettre en place un serveur LDAP et ce que ca implique, autant appeler un grep en rsh dans un fichier localisé sur un serveur précis pour faire mes résolutions, ca sera aussi efficace.
C'était juste histoire de dire un peut méchament que le support LDAP dans postfix laisse un peut a désirer et est franchement sous optimal par rapport aux capacités/fonctionnalites de LDAP.
Pour répondre de manière générale à un peu tous les posts:
La première version de sendmail a 20 ans : 1983 dans BSD 4.1c (y en a un paquet ici qui étaient encore en couche culote et surement les plus virulents).
A l'époque, TCP/IP avait officiellement 1 ans d'existance en prod sur ARPANET.
A l'époque, et jusque dans les années 95, un relais de SMTP etait "ouvert" par définition.
Et on pourrait contiuer longtemps comme ca...
Bon, ca n'excuse rien mais:
Sendmail n'est aujourd'hui pas plus troué qu'un autre MTA (c'est rigolo comme les releases de postfix passent inapercu ....) même si il a un très lourd passif.
Sendmail a beacoup évolué et n'est plus aussi monolitique que l'on veut le laisser croire.
Sendmail malgès sa très grande flexibilité et sa très grande finesse de configuration n'est pas compliqué a configurer. Par contre celui qui tripote à la main son sendmail.cf est un abruti. (a moins d'écrire le m4 qui va bien) Dans sa lente, progressive mais sure évolution, le fichier de conf sendmail.cf est aujourd'hui a considerer comme un fichier de conf interne auquel on ne doit pas toucher...
ca c'est un fichier de conf par exemple :
define(`confDEF_USER_ID',``8:12'')dnl
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`LOCAL_MAILER_FLAGS', `ShPfn')dnl
define(`LOCAL_MAILER_ARGS', `procmail -a $h -d $u')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
FEATURE(`redirect')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`local_procmail')dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`dnsbl')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
MAILER(`procmail')dnl
Si ca c'est compliqué... (et encore, il l'est...)
Pour les utilisateurs de Debian, jeter un coup d'oeil au package Debian (http://packages.debian.org/unstable/mail/sendmail.html(...)), il est tout simplement génial.
En terme de fonctionnalité, Sendmail est quasiment toujour le premier à implémenter les dernières RFC (même si historiquement, il a eu fait de grosses disgression).
Qu'on me parle pas du support LDAP de Postfix (MTA que j'aime beacoup par ailleur), les concepteurs de LDAP doivent être dégoutés, pourquoi se faire chier, rsh+grep dans un fichier à plat aurait fait aussi bien... C'est valable pour toutes les sources de data Postfix, c'est "élégant" a utiliser, mais c'est carément primitif en terme d'inplémentation et d'efficacité.
Ok, simple, robuste... mais dans ces cas la je ne connais pas plus simple et robuste que la bonne vielle feille de papier et le stylo...
Certe Postfix est plus "scalable" que Sendmail (et encore, si celui ci est mal configuré) à l'exeption près évoqué ci dessus, mais l'overhead de base est carement plus important pour une machine non dédié à du routage de courrier.
Bon, je m'arrête là. En conclusion:
Oui, Sendmail a un lourd historique qui ne lui donne pas une bonne image.
Oui, de part d'autres aspects de ce même historique, Sendmail mérite le respect.
Oui, Sendmail est a la pointe des RFC et a une liste de fonctionalités impressionantes.
Non, Sendmail n'est pas aujourd'hui plus troué que les autres.
Non, Sendmail n'est pas un enorme tas de code décrépit et pourri.
Oui, Sendmail évolu progressivement et toujour dans le bon sens.
Oui, l'évolution est lente, mais le passif et lourd et les compromis évolution / compatibilité / new feature / cleanup / rewrite sont toujour difficiles a faire.
Oui, Sendmail est performant et avec un faible overhead de départ.
Oui, Sendmail est simple a configurer mais est extrèmement flexible.
Oui Sendmail est compliqué dans les config bien tordu. mais a config tordue conf tordue.
Oui, Postfix rulez, mais Postfix Rulez <> Sendmail pourri.
Oui, Postfix souvent plus simple.
Oui Postfix extrèmement scalable, mais aussi plus gourmant de base.
Oui Postfix ridicule sur certains points, mais Postfix jeune.
Oui Postfix beton sur d'autres points, mais Postfix a été écrit avec des données de départ toutes autres, Postfix jeune.
/Mode pétage de pomb on
Oui, certains trolleurs boutoneux feraient mieux de fermer leurs gueules quand ils ne savent pas de quoi ils parlent.
(Valable pour beaucoup d'autres sujets).
/Mode pétage de plombs off
Quand aux choix des distribs, Oui c'est bien que ce ne soit pas nécessairement le MTA par défaut, il y a encore plus simple et plus léger. (d'ailleur ce n'est pas non plus Postfix par défault sur Debian ou Mandrake....).
Il y a aussi les curseur hardware animé et composés avec RENDER, et surtout l'intégration de Fontconfig et de xft2 pour la gestion et le rendu des fontes.
hummm, j'ai une Millenium II et une G200 PCI dans ma machine et je n'ai jamais eu de freeze. Pareil chez un ami qui a une mystique et une Millenium I.
Pour les version AGP (G200/400 ...), c'est vrai, il y avait des freeze en 3D, mais t'est un peu dur, le CVS d'XFree contiend les corrections (ok, il faut attendre le 4.3, mais c'est pareil pour tout le monde)...
Dans le genre truc global (pas necessairement orienté jeux, certe), pour ceux qui se souviennent du projet farenheit de sgi lamentablement coulé par Microsoft... (Microsoft participait au projet et a racheté tous les droits sur le code avant de tout couller...).
Parce que:
1 - pour les connaitre ce sont des branquignoles (je suis sur que ta mere ferait un meilleur boulot qu'eu) qui passent plus de temps à faire leur petites gueguerres politiques qu'a bosser.
2 - parce que 2K c'est une grosse saloperie assez pointue à déployer dans un environnement complexe et que .net n'est rien d'autre que 2K avec quues erreurs de conceptions corrigées, ce qui aide quand on est des branques.
3 - parce qu'il sont prix par les coucougnettes par Microsoft a savoir qu'il en ont déjà partout et que ce n'est donc qu'une évolution de leur parc et pas une refonte du SI impossible quand 1.
(j'espère que mes employeurs et ses clients lisent pas lxfr sinon ....)
-> Pourquoi des jeunes SSII preferent utiliser ASP.Net (pourtant voue a disparaitre) et VB plutot que PHP et Java
1 - C'est quoi les chiffre ?
2 - heureusement que tu précise jeunes: elles n'ont en général pas le temps d'obtenir le status de "établie depuis plus de x ans".
3 - Parce qu'avec, selon tes propres mots, des outils qui te machent le boulot, ils ont l'impression d'être les meilleurs du monde, de savoir tout faire et bien, alors qu'il sont au dessous de tout mais bon, c'est beau la naiveté et l'entousiasme....
-> Pourquoi tout le monde utilise Office ou presque
1 - Parce qu'il a la supériorité de l'ancienneté
2 - a cause de 1, tout le monde ne connait que ca
3 - toujour 1, personne ne connait autre chose
4 - 1,2,3 n'aident pas les éditeurs, programmeurs du libre and co à le détroner.
5 - je passe sous silence les autres argument du genre std proprio, incompatibilité volontaires etc.........
6 - malgrès 1,2,3,4,5 des alternatives libres arrivent lentement mais surement à maturité mais se font défoncer par des arguments comme les tiens.
Yep,
C'est complètement hors sujet (shame on me...) mais je ne peut résister:
Un jour alors que je discutais réseaux avec un admin sys crosoft, je me suis rendu compte avec stupeur qu'il était persuadé et croyait dur comme du fer que TCP/IP était une invention de Microsoft.... et c'était il y a 4 ans!
En gros, les croyances de Samuel autour des technologies Microsoft, on s'en fou. Ce qui est interressant c'est ce qu'il dit dans le reste losrque l'on coupe le paragraphe incriminé.
Pour répondre a moi même, je sais bien que "il faut ... il faut", c'est vite dit et que avec des si on mettrait Paris en bouteille.
Enfin pour répondre à anonyme512, il est plus que vrai que le défault majeur de XFree/DRI explicant le peu d'implication des développeurs est le manque global de doc du code du projet vis à vis de la complexité de celui ci.
La, pareil, fadrait un petit remède miracle ou une petite incatation vodoo histoire de corriger le tir.
Ok, directfb est interressant, mais répond à 5% de la problématique en réinventant la roue.
Pourquoi xdirectfb ?
Parceque directfb n'est qu'une interface framebuffer noyaux (on a déjà) avec quelques primitives accélérées kernel (les drivers xfree natifs vont beaucoup plus loin). Maintenant dans le framebuffer on veut gérer des fenêtres et une cohabitation entre plusieurs applis. Donc ? et bien on a rien trouvé de mieux que de faire un serveur X s'appuyant sur directfb... Et si je veut utiliser de la 3D cablé avec directfb, je fait comment ? je réinvente un DRI en user space dans la lib directfb et je code un nouveau DRM dans mes drivers kernel directfb ?
On tourne en rond !!!
Certe, pour du mono appli genre embarqué, directfb est un killer. Mais au lieu de se disperser, imaginez que ces mêmes personnes aient réalisés le merge entre le drm et le linuxfb plustot que de travailler dans leur coin. On obtiend un super linuxfb utilisable en direct rendering exactement comme directfb (profitant des irq pour la synchro verticale, les dma, ...) avec un xfree nouvelle génération tel qu'évoqué précédement pouvant s'appuyer dessus.
Au lieu de réunifier les sous systèmes créés à l'origine pour répondre à une problématique précise, on disperse tous nos efforts dans dix mille directions à la fois...
X11 est un système super léger, si si je vous jure, il tounais déjà quasi a l'identique sur les machines des années 80 avec qques méga de ram.
XFree (pas X11) souffre aujourd'hui de quelques défaults/limitations d'implémentation.
(pour les défault de X11, c'est une autre histoire et je vous invite a suive les dev sur la liste XFree et dans le CVS et lire les papiers de Keith Packard pour voir les evolutions apportés aux pblm de design de X: XRender, XRand, ShadowFB, fontconfig, XCursors ou un truc du genre, etc...).
Plustot que de foutre à la benne 20 ans d'expérience il suffirait de corriger ces quelques défault d'implémentation pour que tout le monde soit content sans même que vous vous rendiez compte des défault de conception/age de X11 évoqués entre parenthèses au paragraphe précédent.
Optimiste parce qu'il y a des solutions et que l'on se dirige lentement vers elles.
Pessimiste à cause de cette lenteur et également du fait que les quelques développeurs XFree, a tord ou a raison sont très conservatifs. Dans leur contexte, je les comprend, les chiffres sont là:
Développement du driver 2D ATI: ATI + revu et corrigé par deux ou trois personne de XFree (chapeau ATI).
Développement du driver 3D ATI Rage, 7500, 8500, 9x00: a peut de choses près 1 personne (Keith Whitwell) et encore il est payé pour et seulement pour un modèle precis de la dernière génération. (et il en sort un paquet par ans de carte. lire: dès qu'une nouvelle carte sort, on oubli les vielles même si le driver n'est pas fini).
Développement du driver 3D Mach64: 2 personnes qui sont reparti de rien, le driver n'ayant pas de sponsor commercial, Keith a arrêté de travailler dessus (c'était sur son temps perdu).
Developpement driver Matrox: Après une participation de Matrox pour le driver 2D et 3D, plus rien. Le driver est en mode pseudo maintenance alors qu'un bon dépoussiérage vous blufferai sur ce que l'on peut encore tirer de ces cartes.
Travail sur OpenGL: Brian Paul. Pourtant c'est un sacré monstre.
Travail évoqué précédement sur le gestionaire de texture unifié: 1 personne Ian Romanick qui travaille pour IBM.
Je passe sur le problème nvidia et de leur driver fermé / politique vis a vis des specs et ce ne sont pas les seuls...
Conclusion:
Pour avoir
- plein de drivers
- de bons drivers
- des drivers performant donc s'appuyant sur une bonne infrastructure.
Il faut plus de développeurs.
Comment ?
Ben c'est là que j'ai pas la solution. Faut arriver a impliquer/interresser plus de monde, plus de boites, plus de sponsors.
Tout le monde utilise XFree (même sous Windows, j'en connais plein...), il a le mérite d'exister tel qu'il est. D'un autre coté, et c'est là ou est le paradoxe, tout le monde râle, mais tout le monde s'en contente.
Comparez le nombre de lignes de codes de XFree / DRI / DRM / Mesa et de sa poigné de développeurs avec
le nbre de lignes de code source de Linux et son bon millier de développeurs majeurs.
Pourtant la complexité des deux projets est similaire. Je vois mal aujourd'hui Linus faire avancer Linux avec moins d'une vingtaine de développeurs majeurs. Même s'il a les meilleures idées du monde en ce qui concerne "comment faut faire" au niveau de l'architecture logicielle et vers quoi il faut aller.
Alors si qqu'un a le remède miracle quand à la désertion des développeurs qu'il agisse et vite sinon on est pas près de sortir de ce paradoxe.
Bienvenu dans la quatrième dimension !
de support correct pour l'ATI Mach64, qui est antidéluvienne,
La prochaine version di DRI devrai te combler, quelques développeurs (2-3) se sont mis au travail en passant par la difficile phase d'apprentissage de l'architecture et des sources de XFree/DRI et ca a fini par porter ses fruits.
En conséquence, certains matériels restent de manière totalement absurde de coté pour certaines fonctionnalités (typiquement XVideo, XRender), alors qu'une implémentation par défaut le leur donnerait au prix certes de performances médiocres.
C'est le cas pour XRender, cela a d'ailleur des effets pervers: beaucoup de cartes n'ont pas nécéssairement le support adéquat révé pour l'implémenter, d'où la difficulté, d'où le fait que l'on reste sur plus de 90% des drivers sur l'implémentation soft par manque de codeurs qualifiés sur XFree.
La disparité des interfaces et sous systèmes a prendre en compte participe à la difficulté d'écriture des drivers XFree. Prenez par exemple le problème de switch vers une VC Linux: pas de support noyau, pas de moyen de com entre les deux, pas d'interaction possible entre les deux d'où une aproche empirique de XFree pour sauvegarder et restaurer les bons registres avant et après le switch.
Avantage: system independant.
Inconvénient: un truc bouge dans la gestion console du noyaux; ca casse. Un truc bouge dans le code accéléré de XFree sans prendre garde à cet obscur cas particulier; ca explose. Le drivers n'en est pas pour autant de mauvaise qualité.
Les cartes graphiques actuelles deviennent des monstres de complexités. A coté, la complexité de nos UC et CPU fait presque palle figure. La tandance vers laquelle je crois il faudrais se tourner c'est de considerer nos cartes comme de vrai machines leur drivers devenant aujoud'hui de propres OS.
Alors, un support OS host devient une évidence (merge fb/drm/...) et une base commune de code peut émerger, simplifiant l'écriture de driver.
Un driver carte ethernet Linux est facile a écrire aujourd'hui, même avec une plétore d'accélérations (zerocopy/checksum, bientot crypto ...) même un portage du système complet sur un nouveau CPU/Architecture se fait de plus en plus facilement. Pourquoi ?
- Base système commune (c'est le plus important)
- 10 ans d'expérience et de maturation pour construire cette infrastructure système (Kernel arch independent).
- Beaucoup de développeurs et un bon arbitre.
L'architecture de XFree a fait un bout du chemin (le DDX pour la 2D) mais necessite aujourd'hui une infrastrucure noyaux qui se cherche pour tirer parti de nos rolls du pixel.
Pour répondre à la problématique "partie réseau qui me sert peu et ralentit tout":
C'est faux: X11 utilise en local les socket Unix et pas TCP/IP. De plus une étude a été mené par Keith Packard il y a quelques années déjà pour savoir si un mode mémoire partagé pour la transmission des messages entre le client et le serveur ne serait pas plus avantageux. Le résulat est éloquent: le mode message est bien plus léger et plus rapide, la gestion des ordres X11 en mode block au travers d'un segment de mémoire partagé faisant écrouler les perfs.
Par contre, pour la manipulation des Bitmaps, l'extention XShm est bien entendu indispenssable.
Néanmois, pour parler de celle ci, même en l'utilisant, de part la très faible interaction entre le noyaux et le serveur, plusieurs copies mémoire sont réalisés avant que vous obteniez votre image à l'écran. Ici pas de zérocopy! (dito pour XVideo). Quand on sait ce que coute une copie mémoire sur du graphique ....
Comment définitivement régler le pblm et obtenir les perfs des interfaces graphiques client side (directfb/gtkfb) tout en gardant l'ensemble des fonctionnalités X11 ? (séparation conceptuelle client / serveur d'ailleur respectée même avec le DRI pour OpenGL/GLX) ?
- remonter la gestion de la mémoire graphique/texture/video... au niveau d'un nouveau gestionnaire kernel (la VM graphique en quelque sorte).
- réviser la XShm pour éliminer les incohérences rendant difficile l'implémentation d'un fonctionnement ZeroCopy. (histoire de travailler non plus avec des segment de mémoire partagé IPC Unix, mais avec un segment partagé entre la VM graphique, le serveur X et le client X si celui ci est local. Du coup, l'extention deviendrait presque transparente vu du programmeur).
On obtiendrais alors les avantages du client side sans avoir plus tard a inventer des truc a la metaframe and co pour palier au pblm.
Boouuuhhh, faut que je me calme, j'ai pas l'habitude d'écrire de tels romans!! ;-)
Juste quelques commentaires sur XFree86 et les perfs:
XFree86 fait pas mal de concessions sur les perfs au nom de la sacro sainte portabilitée et passe souvent son temps a réinventer la roue. On peut citer par exemple la gestion complète en userspace de tous les devices d'entrés (en train de changer pour Linux en branche HEAD et kernel 2.5 qui utilise l'events API), la réimplémentation complète de toute la gestion PCI (qui quand y a des bugs et interfere mal avec le noyau crashe la machine), réimplémentation de l'I2C, des drivers tuner et de beaucoup de choses dans la Xvidéo extention étant du ressort de V4L(2) sous Linux (attention, je n'ai pas dit que la XVideoEntention n'était pas nécessaire, cetaines choses sont de sont ressort et pas de celui de V4L).
Du fait de son extrème portabilité et de son mode full userspace, et bien exit les transferts DMA pour les pixmaps, exit la synchro verticale avec les interrupts et j'en passe...
L'arrivée du DRI commence a bouleverser les choses et certains drivers commences a profiter de cette petite incursion kernel (DRM) pour détourner sa raison originelle (la 3D client side) pour par exemple tranferrer les images YUV (Xvideo) en DMA (ATI), dans le CVS du DRI/DRM on commence a voir apparaitre la gestion du vertical retrace sous interruption pour décharger le CPU et la carte GFX (pourquoi calculer 2000 frame secondes quand votre écran en affiche au mieux ~100 sans parler des effets de fliker). D'ici que le serveur X puisse utiliser cette fonctionnalité, y a q'un pas. (driver ATI et MGA).
(enfin pas tout a fait, faudrai que le serveur X ait enfin un client DRI intégré ou que les gens de XFree décident de définir un DRM like pour autre chose que la 3D et le DRI).
Si on essay d'avoir une vision plus globale, un XFree "optimisé" tirerais au mieux parti de l'infrastructure fournie par le kernel:
- utilisation de l'interface FrameBuffer pour acceder à la carte au lieu de réinventer la gestion PCI, SBUS etc...
- utilisation de l'API native pour la gestion des claviers/pointeurs.
- avec un raprochement du DRM et de l'interface FB, l'utilisation systématique des DMA pour les transferts de données supéreurs à une certaine taille.
- utilisation des interruptions pour la gestion de la synchro verticale.
- utilisation systématique de V4L pour le partie input de la XVideoExtention.
- gestion mémoire de la carte plus évoluée et unifié au niveau kernel entre le DRI/DRM, XFree, FB, V4L (très important pour les carte type Matrox Marvel, ou ATI All In Wonder). Les problématiques de gestion de la mémoire de ces cartes, sans être aussi complexe que la VM du noyau, sont de moins en moins triviales. Un premier travail est effectué dans ce sens dans une branche particulière du DRI, visant à ramener a terme la gestion de la mémoire des textures dans le noyau pour la partager entre tous les clients 3D.
Bref, beaucoup de chemin reste a parcourir, mais le train est en marche même si c'est loin d'être un TGV. Rien en tout cas ne necessite une remise en cause globale de ce qui existe en terme d'architecture haut niveau. Ce n'est qu'un pblm d'implémentation.
Par contre messieurs les codeurs de toolkits graphiques et d'application, s'il vous plais, validez votre design, profilez vos aplications et vos librairies, en 6 ans d'évolution, c'est devenu une catastrophe sur ma machine alors que les applis sont juste un peut plus jolie et ne font strictement rien de plus... Bien codé, l'ensemble devrais être aussi sinon plus rapide que l'équivalent de l'époque.
Un dernier mot en ce qui concerne XFree: Un grand merci au personnes de XFree et du DRI et que la force soit avec vous.
Pour les currieux, estimez a combien se monte le nombre total de personnes directement impliqués dans le dev de XFree et du DRI, vous serez étonnés. Comme quoi les choses tiennes à pas grand choses.
Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))
[^] # Re: Keith Packard viré de XFree86
Posté par efuste . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 3.
[^] # Re: Une question - directfb
Posté par efuste . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 4.
# Re: Keith Packard viré de XFree86
Posté par efuste . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 10.
C'est devenu la mode en ce moment. Après Bush, la BOD de Xfree86....
Le truc qui me fait gerber dans l'histoire, c'est que cette même équipe qui fout Keith dehors pour des pseudo raisons de non transparence, de manque d'esprit opensource est le noyau dur le plus réac et conservateur qui soit ...
Arretons le débat XFree86 gourmant / XFree86 lent. C'est faux et archi faux. Les principaux problèmes de XFree86 sont :
- une non coopération avec le système sous jacent.
- le manque d'un support kernel correct (ca arrive doucement avec les mutations futures du DRI)
- le manque de drivers 100% corrects
- un immobilisme et un conservatisme dans les possibilités d'évolutions de XFree86 pour corriger ses quelques (gros) défaults d'impléméntations, qui etoufe le projet.
Reportez vous à http://linuxfr.org/2002/10/28/10118.html(...)
J'avais a l'époque beaucoup évoqué les pblm de design de XFree86, le pourquoi du comment et le futur envisageable.
J'avais été assez modéré sur l'atitude de la core team parce que c'est eux qui tirais même lentement le projet vers l'avant mais là, ca a beau être des bêtes, des killers, ils n'en sont pas moins des sales putain de réac conservateurs.
Si, le code de Xfree86 est accessible depuis qques temps en CVS, si les listes sont toutes open depus quelques mois seulement, c'est sous la pression de la communauté opensource et les impératifs dû au projet DRI/DRM beaucoup plus ouvert et dans l'esprit que nous connaissons. C'est en tout cas pas grace à leur adhésion à cet espris qu'il prennent ici pour pretexte pour virer Keith.
Toutes les avancés de Xfree86 4.3 visible pour les utilisateurs à savoir RandR, Fontconfig, XCursor Xr, Render sont des projets et du code menés par Keith.
Dans les dernières discutions sur linux-fb-devel et dri-devel, j'ai cru rêver, l'équipe DRI, les personnes du fb linux, Linus en personne, Alan Cox, tous discutaient de l'intégration et du futur du DRI / FB / XFree. mes rêves les plus fou ( voir toujour http://linuxfr.org/2002/10/28/10118.html(...) ) ont une chance de devenir réalité.
Alors vive Keith, vive un Fork de XFree86.
Quand au pblm de licence. XFree ne DOIT PAS changer de licence. La raison est simple, XFree86 est devenu la référence X11, c'est aujourd'hui l'implémentation de référence du X Consortium. Un fork GPL/LGPL lui ferait perdre cette legitimité aquise en 10 ans de dur travail et qui permet à la comunauté open source de faire évoluer le standard X11 officiellement (et non pas sous forme d'extention spécifiques XFree86).
D'ailleur, je propose un nom à ce fork : XFree
Ben oui, le nom officiel du projet actuel est XFree86 et l'équipe actuelle défend depuis des années ce 86 qui n'a plus de sens aujourd'hui et ce de manière presque intégriste.
[^] # Re: \o/ oué !!!
Posté par efuste . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 7.
:0 ou :0.0 => socket Unix
Le plus performant est bien entendu le deuxième cas.
(de meme pour les autres display).
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par efuste . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 2.
Je sens que ca derape alors j'arreterai là.
C++, ben ouais réécrivons tout en C++, le kernel, la libc (plonk), après on ecrira des super outils de la mort qui tu pour profiler systematiquement tout ca étant donné qu'aubout d'un moment, n'étant même plus capable de savoir ce que fait réellement le code, ben faut tracer, analyser, bencher a la methode vodoo, j'ty rajoute un pti buffer de truc par ci et par la sinon mon bastringue fait houatmille millier d'intanciations allocation desalocation secondes et ca ramme, ca bouffe de la ram. puis derière j'ty pond deux trois script magiques pour analyser les sections de code générées pour voir pourquoi mon "hello world" genère un code objet de 20Mo et alloue 100Mo de ram en runtime, pius après je me rend compte que mes trois putains de classes X Y et Z ben c'est caca et je devrai avoir à la place un truc genre V W, mais la je remet pas en cause l'implementation de mes objets, mais l'ensemble de la conception parce que de toute manière je sais plus comment est branlé tout le reste vu qu'il me faudra au moins 3 mois pour retrouver comment mon truc U derive de mon machin T lui même hérité de ..... Bon un pti pointeur bien placé par là et hop le tour et joué et puis dans tout ce merdier bien opaque (c'est la philo du machin, c'est bien ) personne n'y vera que du feu...
Merde, ca rame quand même sur ma machine ben oais, ca s'apelle Mozilla.
Et puis tous les developpeurs windows font du C++ non ? Ben oui, c'est MSVC++ le non du compilo non ?
Quand à Carmack, il a eu le temp de le paufiner son design avant de passer au c++, Doom1 doom2, Quake 1,2,3 bon je lui fait confiance pour passer au c++ maintenant, puis on peut pas, à lui, reprocher le fait qu'il code en ++ "parceque c'est un super language qui resoud même le fons du pblm à ta place". Tu chi de la déclaration, des classes, de l'objet et hop ca marche, sinon ben c'est pas ta faute, c'est le compilo, c'est l'os, ben coment tu gère le truc T et le machin M ? Ha, j'sais pas c'est l'objet O, quel boulet le développeur de O. Par contre le design D, ca personne connais, et le développement incrémental si cher a notre comunauté OpenSource ca marche pas bien avec ++ ? ben c'est que c'est de la merde alors.
Alors bon, c'est sur Mozilla est en ++ et l'histoire nous a montré que du coup il n'avait jamais de trou de sécurité....
A la vue de la pluspart (j'ai pas dit tous .... mais a tout bien réfléchi, presque) tes posts dans cette news, y a deux solutions: Soit ca te fait simplement tripper de foutre la merde et d'exiter les gens avec des propos gratuitements provocateurs et sans intérêts réels (un trollermaster ?), a mois que ce soit dans l'expectative de te recycler dans la socio (nouvelle thèse ?), ou alors on a affaire a qq'un du style des types qui viennent de découvrir l'informatique depuis moins de 2 ans et qui savent tout sans avoir jamais rien fait genre adolescent boutoneu. Vu la date de ta Thèse, je penche plustot pour la première solution.
Sans rancune.
Un vieux con qui pense très sérieusement se recycler très prochainement dans la plomberie/electricité/maconerie.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par efuste . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
Quand au code généré, on en parle même pas, de la grosse emulation soft pour les exceptions et j'en passe...
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par efuste . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 1.
Ouupps, je voulais dire exim.
bref, un autre que satanmail euuuu sendmail.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par efuste . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 3.
Je ne m'adressais pas a toi en particulier:
Pour répondre de manière générale à un peu tous les posts:
Tu remarquera que je n'ai pas critiqué Qmail.
1- Maintenant si tu veur parler perf, faut voir les conditions de test.
Ton Qmail avec une liaison satellite meme a haute vitesse (d'une manière générale, grande bande passante et forte latence), ben il va se vautrer par rapport à un Sendmail.
voir:
http://www.cs.helsinki.fi/linux/linux-kernel/2003-09/0002.html(...)
2 - Qmail est un excelent mailer construit sur une base plus saine que sendmail et plus simple car il ne supporte pas tout. cf 1 et mon post precedent. Faut pas me faire dire ce que je n'ai pas dit :-)
3 - Oui et alors ? Sendmail est toujour majoritaire, l'est historiquement parcequ'il était un peut tout seul avant... il y a moins de 10 ans tu demandais à qq'un ce q'était Internet il t'aurait répondu kezako ? Y avait pas beaucoup de personnes non plus avec des serveur mail sous win3.11 ou 3.51 .... Ajoud'hui le reste du parc dans les stats c'est du MS ou de la gateway antivirale...
Qmail est troisième cool. A mon avis dans des stats plus récentes postfix aurra progresse.
4 - Je pensait que c'etait Qmail. Certe.
5 - Combien de bug critiques dans sendmail dans des cas de config ultra tordu "que de toute manière les zautres savent pas faire donc risquent rien...." Bon, cette fois il est plustot balaize mais très objectivement ca arrive si souvent que ca ????
6 - je parlais de l'accès au map alias, mbox, mailserver etc... ou ce que tu voudra, dans du LDAP, SQL etc...
Quand je vois comment c'est fait dans postfix pour le LDAP, plustot que de me faire chier a mettre en place un serveur LDAP et ce que ca implique, autant appeler un grep en rsh dans un fichier localisé sur un serveur précis pour faire mes résolutions, ca sera aussi efficace.
C'était juste histoire de dire un peut méchament que le support LDAP dans postfix laisse un peut a désirer et est franchement sous optimal par rapport aux capacités/fonctionnalites de LDAP.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par efuste . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 10.
Pour répondre de manière générale à un peu tous les posts:
La première version de sendmail a 20 ans : 1983 dans BSD 4.1c (y en a un paquet ici qui étaient encore en couche culote et surement les plus virulents).
A l'époque, TCP/IP avait officiellement 1 ans d'existance en prod sur ARPANET.
A l'époque, et jusque dans les années 95, un relais de SMTP etait "ouvert" par définition.
Et on pourrait contiuer longtemps comme ca...
Bon, ca n'excuse rien mais:
Sendmail n'est aujourd'hui pas plus troué qu'un autre MTA (c'est rigolo comme les releases de postfix passent inapercu ....) même si il a un très lourd passif.
Sendmail a beacoup évolué et n'est plus aussi monolitique que l'on veut le laisser croire.
Sendmail malgès sa très grande flexibilité et sa très grande finesse de configuration n'est pas compliqué a configurer. Par contre celui qui tripote à la main son sendmail.cf est un abruti. (a moins d'écrire le m4 qui va bien) Dans sa lente, progressive mais sure évolution, le fichier de conf sendmail.cf est aujourd'hui a considerer comme un fichier de conf interne auquel on ne doit pas toucher...
ca c'est un fichier de conf par exemple :
define(`confDEF_USER_ID',``8:12'')dnl
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`LOCAL_MAILER_FLAGS', `ShPfn')dnl
define(`LOCAL_MAILER_ARGS', `procmail -a $h -d $u')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable')dnl
FEATURE(`redirect')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`use_cw_file')dnl
FEATURE(`local_procmail')dnl
FEATURE(`access_db')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`dnsbl')dnl
MAILER(`local')dnl
MAILER(`smtp')dnl
MAILER(`procmail')dnl
Si ca c'est compliqué... (et encore, il l'est...)
Pour les utilisateurs de Debian, jeter un coup d'oeil au package Debian (http://packages.debian.org/unstable/mail/sendmail.html(...)), il est tout simplement génial.
En terme de fonctionnalité, Sendmail est quasiment toujour le premier à implémenter les dernières RFC (même si historiquement, il a eu fait de grosses disgression).
Qu'on me parle pas du support LDAP de Postfix (MTA que j'aime beacoup par ailleur), les concepteurs de LDAP doivent être dégoutés, pourquoi se faire chier, rsh+grep dans un fichier à plat aurait fait aussi bien... C'est valable pour toutes les sources de data Postfix, c'est "élégant" a utiliser, mais c'est carément primitif en terme d'inplémentation et d'efficacité.
Ok, simple, robuste... mais dans ces cas la je ne connais pas plus simple et robuste que la bonne vielle feille de papier et le stylo...
Certe Postfix est plus "scalable" que Sendmail (et encore, si celui ci est mal configuré) à l'exeption près évoqué ci dessus, mais l'overhead de base est carement plus important pour une machine non dédié à du routage de courrier.
Bon, je m'arrête là. En conclusion:
Oui, Sendmail a un lourd historique qui ne lui donne pas une bonne image.
Oui, de part d'autres aspects de ce même historique, Sendmail mérite le respect.
Oui, Sendmail est a la pointe des RFC et a une liste de fonctionalités impressionantes.
Non, Sendmail n'est pas aujourd'hui plus troué que les autres.
Non, Sendmail n'est pas un enorme tas de code décrépit et pourri.
Oui, Sendmail évolu progressivement et toujour dans le bon sens.
Oui, l'évolution est lente, mais le passif et lourd et les compromis évolution / compatibilité / new feature / cleanup / rewrite sont toujour difficiles a faire.
Oui, Sendmail est performant et avec un faible overhead de départ.
Oui, Sendmail est simple a configurer mais est extrèmement flexible.
Oui Sendmail est compliqué dans les config bien tordu. mais a config tordue conf tordue.
Oui, Postfix rulez, mais Postfix Rulez <> Sendmail pourri.
Oui, Postfix souvent plus simple.
Oui Postfix extrèmement scalable, mais aussi plus gourmant de base.
Oui Postfix ridicule sur certains points, mais Postfix jeune.
Oui Postfix beton sur d'autres points, mais Postfix a été écrit avec des données de départ toutes autres, Postfix jeune.
/Mode pétage de pomb on
Oui, certains trolleurs boutoneux feraient mieux de fermer leurs gueules quand ils ne savent pas de quoi ils parlent.
(Valable pour beaucoup d'autres sujets).
/Mode pétage de plombs off
Quand aux choix des distribs, Oui c'est bien que ce ne soit pas nécessairement le MTA par défaut, il y a encore plus simple et plus léger. (d'ailleur ce n'est pas non plus Postfix par défault sur Debian ou Mandrake....).
Un vieux con, pas si vieux pourtant, sniff.
[^] # Re: Mauvaise idee
Posté par efuste . En réponse à la dépêche Libre et rémunération ?. Évalué à 1.
[^] # Re: XFree 4.3.0 annoncé
Posté par efuste . En réponse à la dépêche XFree 4.3.0 annoncé. Évalué à 8.
[^] # Re: Superbe merde
Posté par efuste . En réponse à la dépêche Drivers ATI pour Linux. Évalué à 1.
Pour les version AGP (G200/400 ...), c'est vrai, il y avait des freeze en 3D, mais t'est un peu dur, le CVS d'XFree contiend les corrections (ok, il faut attendre le 4.3, mais c'est pareil pour tout le monde)...
[^] # Re: Ça va sans doute améliorer les choses
Posté par efuste . En réponse à la dépêche OpenGL 2.0 strikes back. Évalué à 2.
http://www.opensg.org/OpenSGPLUS/index.EN.html(...)
conceptuellement plus bordelique, mais avec du code plus avancé et un modèle qui tend progressivement à être équivalent:
http://www.openscenegraph.org/(...)
[^] # Re: OpenGL 2.0 strikes back
Posté par efuste . En réponse à la dépêche OpenGL 2.0 strikes back. Évalué à 1.
http://www.mips.com/products/index.html(...)
[^] # Re: Va t-on passer au tout Microsoft ?
Posté par efuste . En réponse à la dépêche L'action de l'Etat pour le développement de la société de l'Information. Évalué à 1.
Parce que:
1 - pour les connaitre ce sont des branquignoles (je suis sur que ta mere ferait un meilleur boulot qu'eu) qui passent plus de temps à faire leur petites gueguerres politiques qu'a bosser.
2 - parce que 2K c'est une grosse saloperie assez pointue à déployer dans un environnement complexe et que .net n'est rien d'autre que 2K avec quues erreurs de conceptions corrigées, ce qui aide quand on est des branques.
3 - parce qu'il sont prix par les coucougnettes par Microsoft a savoir qu'il en ont déjà partout et que ce n'est donc qu'une évolution de leur parc et pas une refonte du SI impossible quand 1.
(j'espère que mes employeurs et ses clients lisent pas lxfr sinon ....)
1 - C'est quoi les chiffre ?
2 - heureusement que tu précise jeunes: elles n'ont en général pas le temps d'obtenir le status de "établie depuis plus de x ans".
3 - Parce qu'avec, selon tes propres mots, des outils qui te machent le boulot, ils ont l'impression d'être les meilleurs du monde, de savoir tout faire et bien, alors qu'il sont au dessous de tout mais bon, c'est beau la naiveté et l'entousiasme....
1 - Parce qu'il a la supériorité de l'ancienneté
2 - a cause de 1, tout le monde ne connait que ca
3 - toujour 1, personne ne connait autre chose
4 - 1,2,3 n'aident pas les éditeurs, programmeurs du libre and co à le détroner.
5 - je passe sous silence les autres argument du genre std proprio, incompatibilité volontaires etc.........
6 - malgrès 1,2,3,4,5 des alternatives libres arrivent lentement mais surement à maturité mais se font défoncer par des arguments comme les tiens.
[^] # Re: Va t-on passer au tout Microsoft ?
Posté par efuste . En réponse à la dépêche L'action de l'Etat pour le développement de la société de l'Information. Évalué à 1.
C'est complètement hors sujet (shame on me...) mais je ne peut résister:
Un jour alors que je discutais réseaux avec un admin sys crosoft, je me suis rendu compte avec stupeur qu'il était persuadé et croyait dur comme du fer que TCP/IP était une invention de Microsoft.... et c'était il y a 4 ans!
En gros, les croyances de Samuel autour des technologies Microsoft, on s'en fou. Ce qui est interressant c'est ce qu'il dit dans le reste losrque l'on coupe le paragraphe incriminé.
[^] # Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Enfin pour répondre à anonyme512, il est plus que vrai que le défault majeur de XFree/DRI explicant le peu d'implication des développeurs est le manque global de doc du code du projet vis à vis de la complexité de celui ci.
La, pareil, fadrait un petit remède miracle ou une petite incatation vodoo histoire de corriger le tir.
[^] # Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Pourquoi xdirectfb ?
Parceque directfb n'est qu'une interface framebuffer noyaux (on a déjà) avec quelques primitives accélérées kernel (les drivers xfree natifs vont beaucoup plus loin). Maintenant dans le framebuffer on veut gérer des fenêtres et une cohabitation entre plusieurs applis. Donc ? et bien on a rien trouvé de mieux que de faire un serveur X s'appuyant sur directfb... Et si je veut utiliser de la 3D cablé avec directfb, je fait comment ? je réinvente un DRI en user space dans la lib directfb et je code un nouveau DRM dans mes drivers kernel directfb ?
On tourne en rond !!!
Certe, pour du mono appli genre embarqué, directfb est un killer. Mais au lieu de se disperser, imaginez que ces mêmes personnes aient réalisés le merge entre le drm et le linuxfb plustot que de travailler dans leur coin. On obtiend un super linuxfb utilisable en direct rendering exactement comme directfb (profitant des irq pour la synchro verticale, les dma, ...) avec un xfree nouvelle génération tel qu'évoqué précédement pouvant s'appuyer dessus.
Au lieu de réunifier les sous systèmes créés à l'origine pour répondre à une problématique précise, on disperse tous nos efforts dans dix mille directions à la fois...
X11 est un système super léger, si si je vous jure, il tounais déjà quasi a l'identique sur les machines des années 80 avec qques méga de ram.
XFree (pas X11) souffre aujourd'hui de quelques défaults/limitations d'implémentation.
(pour les défault de X11, c'est une autre histoire et je vous invite a suive les dev sur la liste XFree et dans le CVS et lire les papiers de Keith Packard pour voir les evolutions apportés aux pblm de design de X: XRender, XRand, ShadowFB, fontconfig, XCursors ou un truc du genre, etc...).
Plustot que de foutre à la benne 20 ans d'expérience il suffirait de corriger ces quelques défault d'implémentation pour que tout le monde soit content sans même que vous vous rendiez compte des défault de conception/age de X11 évoqués entre parenthèses au paragraphe précédent.
[^] # Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
Optimiste parce qu'il y a des solutions et que l'on se dirige lentement vers elles.
Pessimiste à cause de cette lenteur et également du fait que les quelques développeurs XFree, a tord ou a raison sont très conservatifs. Dans leur contexte, je les comprend, les chiffres sont là:
Développement du driver 2D ATI: ATI + revu et corrigé par deux ou trois personne de XFree (chapeau ATI).
Développement du driver 3D ATI Rage, 7500, 8500, 9x00: a peut de choses près 1 personne (Keith Whitwell) et encore il est payé pour et seulement pour un modèle precis de la dernière génération. (et il en sort un paquet par ans de carte. lire: dès qu'une nouvelle carte sort, on oubli les vielles même si le driver n'est pas fini).
Développement du driver 3D Mach64: 2 personnes qui sont reparti de rien, le driver n'ayant pas de sponsor commercial, Keith a arrêté de travailler dessus (c'était sur son temps perdu).
Developpement driver Matrox: Après une participation de Matrox pour le driver 2D et 3D, plus rien. Le driver est en mode pseudo maintenance alors qu'un bon dépoussiérage vous blufferai sur ce que l'on peut encore tirer de ces cartes.
Travail sur OpenGL: Brian Paul. Pourtant c'est un sacré monstre.
Travail évoqué précédement sur le gestionaire de texture unifié: 1 personne Ian Romanick qui travaille pour IBM.
Je passe sur le problème nvidia et de leur driver fermé / politique vis a vis des specs et ce ne sont pas les seuls...
Conclusion:
Pour avoir
- plein de drivers
- de bons drivers
- des drivers performant donc s'appuyant sur une bonne infrastructure.
Il faut plus de développeurs.
Comment ?
Ben c'est là que j'ai pas la solution. Faut arriver a impliquer/interresser plus de monde, plus de boites, plus de sponsors.
Tout le monde utilise XFree (même sous Windows, j'en connais plein...), il a le mérite d'exister tel qu'il est. D'un autre coté, et c'est là ou est le paradoxe, tout le monde râle, mais tout le monde s'en contente.
Comparez le nombre de lignes de codes de XFree / DRI / DRM / Mesa et de sa poigné de développeurs avec
le nbre de lignes de code source de Linux et son bon millier de développeurs majeurs.
Pourtant la complexité des deux projets est similaire. Je vois mal aujourd'hui Linus faire avancer Linux avec moins d'une vingtaine de développeurs majeurs. Même s'il a les meilleures idées du monde en ce qui concerne "comment faut faire" au niveau de l'architecture logicielle et vers quoi il faut aller.
Alors si qqu'un a le remède miracle quand à la désertion des développeurs qu'il agisse et vite sinon on est pas près de sortir de ce paradoxe.
Bienvenu dans la quatrième dimension !
[^] # Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
La prochaine version di DRI devrai te combler, quelques développeurs (2-3) se sont mis au travail en passant par la difficile phase d'apprentissage de l'architecture et des sources de XFree/DRI et ca a fini par porter ses fruits.
C'est le cas pour XRender, cela a d'ailleur des effets pervers: beaucoup de cartes n'ont pas nécéssairement le support adéquat révé pour l'implémenter, d'où la difficulté, d'où le fait que l'on reste sur plus de 90% des drivers sur l'implémentation soft par manque de codeurs qualifiés sur XFree.
La disparité des interfaces et sous systèmes a prendre en compte participe à la difficulté d'écriture des drivers XFree. Prenez par exemple le problème de switch vers une VC Linux: pas de support noyau, pas de moyen de com entre les deux, pas d'interaction possible entre les deux d'où une aproche empirique de XFree pour sauvegarder et restaurer les bons registres avant et après le switch.
Avantage: system independant.
Inconvénient: un truc bouge dans la gestion console du noyaux; ca casse. Un truc bouge dans le code accéléré de XFree sans prendre garde à cet obscur cas particulier; ca explose. Le drivers n'en est pas pour autant de mauvaise qualité.
Les cartes graphiques actuelles deviennent des monstres de complexités. A coté, la complexité de nos UC et CPU fait presque palle figure. La tandance vers laquelle je crois il faudrais se tourner c'est de considerer nos cartes comme de vrai machines leur drivers devenant aujoud'hui de propres OS.
Alors, un support OS host devient une évidence (merge fb/drm/...) et une base commune de code peut émerger, simplifiant l'écriture de driver.
Un driver carte ethernet Linux est facile a écrire aujourd'hui, même avec une plétore d'accélérations (zerocopy/checksum, bientot crypto ...) même un portage du système complet sur un nouveau CPU/Architecture se fait de plus en plus facilement. Pourquoi ?
- Base système commune (c'est le plus important)
- 10 ans d'expérience et de maturation pour construire cette infrastructure système (Kernel arch independent).
- Beaucoup de développeurs et un bon arbitre.
L'architecture de XFree a fait un bout du chemin (le DDX pour la 2D) mais necessite aujourd'hui une infrastrucure noyaux qui se cherche pour tirer parti de nos rolls du pixel.
Pour répondre à la problématique "partie réseau qui me sert peu et ralentit tout":
C'est faux: X11 utilise en local les socket Unix et pas TCP/IP. De plus une étude a été mené par Keith Packard il y a quelques années déjà pour savoir si un mode mémoire partagé pour la transmission des messages entre le client et le serveur ne serait pas plus avantageux. Le résulat est éloquent: le mode message est bien plus léger et plus rapide, la gestion des ordres X11 en mode block au travers d'un segment de mémoire partagé faisant écrouler les perfs.
Par contre, pour la manipulation des Bitmaps, l'extention XShm est bien entendu indispenssable.
Néanmois, pour parler de celle ci, même en l'utilisant, de part la très faible interaction entre le noyaux et le serveur, plusieurs copies mémoire sont réalisés avant que vous obteniez votre image à l'écran. Ici pas de zérocopy! (dito pour XVideo). Quand on sait ce que coute une copie mémoire sur du graphique ....
Comment définitivement régler le pblm et obtenir les perfs des interfaces graphiques client side (directfb/gtkfb) tout en gardant l'ensemble des fonctionnalités X11 ? (séparation conceptuelle client / serveur d'ailleur respectée même avec le DRI pour OpenGL/GLX) ?
- remonter la gestion de la mémoire graphique/texture/video... au niveau d'un nouveau gestionnaire kernel (la VM graphique en quelque sorte).
- réviser la XShm pour éliminer les incohérences rendant difficile l'implémentation d'un fonctionnement ZeroCopy. (histoire de travailler non plus avec des segment de mémoire partagé IPC Unix, mais avec un segment partagé entre la VM graphique, le serveur X et le client X si celui ci est local. Du coup, l'extention deviendrait presque transparente vu du programmeur).
On obtiendrais alors les avantages du client side sans avoir plus tard a inventer des truc a la metaframe and co pour palier au pblm.
Boouuuhhh, faut que je me calme, j'ai pas l'habitude d'écrire de tels romans!! ;-)
# Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
XFree86 fait pas mal de concessions sur les perfs au nom de la sacro sainte portabilitée et passe souvent son temps a réinventer la roue. On peut citer par exemple la gestion complète en userspace de tous les devices d'entrés (en train de changer pour Linux en branche HEAD et kernel 2.5 qui utilise l'events API), la réimplémentation complète de toute la gestion PCI (qui quand y a des bugs et interfere mal avec le noyau crashe la machine), réimplémentation de l'I2C, des drivers tuner et de beaucoup de choses dans la Xvidéo extention étant du ressort de V4L(2) sous Linux (attention, je n'ai pas dit que la XVideoEntention n'était pas nécessaire, cetaines choses sont de sont ressort et pas de celui de V4L).
Du fait de son extrème portabilité et de son mode full userspace, et bien exit les transferts DMA pour les pixmaps, exit la synchro verticale avec les interrupts et j'en passe...
L'arrivée du DRI commence a bouleverser les choses et certains drivers commences a profiter de cette petite incursion kernel (DRM) pour détourner sa raison originelle (la 3D client side) pour par exemple tranferrer les images YUV (Xvideo) en DMA (ATI), dans le CVS du DRI/DRM on commence a voir apparaitre la gestion du vertical retrace sous interruption pour décharger le CPU et la carte GFX (pourquoi calculer 2000 frame secondes quand votre écran en affiche au mieux ~100 sans parler des effets de fliker). D'ici que le serveur X puisse utiliser cette fonctionnalité, y a q'un pas. (driver ATI et MGA).
(enfin pas tout a fait, faudrai que le serveur X ait enfin un client DRI intégré ou que les gens de XFree décident de définir un DRM like pour autre chose que la 3D et le DRI).
Si on essay d'avoir une vision plus globale, un XFree "optimisé" tirerais au mieux parti de l'infrastructure fournie par le kernel:
- utilisation de l'interface FrameBuffer pour acceder à la carte au lieu de réinventer la gestion PCI, SBUS etc...
- utilisation de l'API native pour la gestion des claviers/pointeurs.
- avec un raprochement du DRM et de l'interface FB, l'utilisation systématique des DMA pour les transferts de données supéreurs à une certaine taille.
- utilisation des interruptions pour la gestion de la synchro verticale.
- utilisation systématique de V4L pour le partie input de la XVideoExtention.
- gestion mémoire de la carte plus évoluée et unifié au niveau kernel entre le DRI/DRM, XFree, FB, V4L (très important pour les carte type Matrox Marvel, ou ATI All In Wonder). Les problématiques de gestion de la mémoire de ces cartes, sans être aussi complexe que la VM du noyau, sont de moins en moins triviales. Un premier travail est effectué dans ce sens dans une branche particulière du DRI, visant à ramener a terme la gestion de la mémoire des textures dans le noyau pour la partager entre tous les clients 3D.
Bref, beaucoup de chemin reste a parcourir, mais le train est en marche même si c'est loin d'être un TGV. Rien en tout cas ne necessite une remise en cause globale de ce qui existe en terme d'architecture haut niveau. Ce n'est qu'un pblm d'implémentation.
Par contre messieurs les codeurs de toolkits graphiques et d'application, s'il vous plais, validez votre design, profilez vos aplications et vos librairies, en 6 ans d'évolution, c'est devenu une catastrophe sur ma machine alors que les applis sont juste un peut plus jolie et ne font strictement rien de plus... Bien codé, l'ensemble devrais être aussi sinon plus rapide que l'équivalent de l'époque.
Un dernier mot en ce qui concerne XFree: Un grand merci au personnes de XFree et du DRI et que la force soit avec vous.
Pour les currieux, estimez a combien se monte le nombre total de personnes directement impliqués dans le dev de XFree et du DRI, vous serez étonnés. Comme quoi les choses tiennes à pas grand choses.
Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))