L'avantage de s'obliger à 100% de couverture, c'est que te repenses ton architecture, pour éviter justement tout ces cas, qui n'existent pas. Coder en imaginant le test, peut faire gagner beaucoup de temps.
C'est plus l'exception que la regle. Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, … Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop.
Concernant les piles logiciels, si chaque bout est correctement testé, l'assemblage est (censé) avoir peu de bugs.
Tester le cas qui marche, oui. Tester quand une partie du materiel a chaud, froid, recoit un rayon cosmique, … ca devient moins probable. Sans compter que le materiel moderne est tres tres fortement asynchrone et multi cpu, ce qui introduit des races conditions que tu vas avoir un mal de fou a voir sur une suite de test unitaire.
Une suite de tests limite les regressions, mais pas les bugs.
Non, c'est plutot realiste comme budget. C'est a peu pres ce que ca coute de developper un telephone. La partie la plus difficile dans la fabrication d'un telephone (ou d'ailleur de tout materiel hardware) est de sourcer les composants.
Quand tu t'appels Samsung, c'est facile, tu es gros et tout le monde veut te vendre un truc. Quand tu es petit, il te faut sortir une grande quantite de cash et payer d'embler pour 10000 ecrans pour en securiser l'approvisionnement. Et tu repetes l'histoire pour tous tes composants. Tu n'as encore rien produit et tes ingenieurs hardware travail pour l'instant sur un prototype avec des composants qu'ils esperent avoir que tu as deja depenser 80% du cout de ta BOM. Une fois que tous les composants sont la, tu essayes de valider un premier run. Si tu as de la chance, tu n'as pas de souci et tu peux continuer. En general, tu as des ajustement a faire et tu refais un tour. Dans le pire des cas, tu dois changer quelques composants et tu tentes de revendre ceux que tu ne veux pas utiliser.
A ce moment la, tu peux commencer a lancer ta production. Va falloir aller voir dans l'usine et verifier que ce qui sort est de qualite et passe les tests. La aussi, il y a de la perte et plus tu fais un truc cutting edge plus tes couts hardware vont monter. Meme si les materiaux choisi semble resistant, il est probable qu'il n'y ait pas d'usine qui ait l'habitude de travailler avec, donc des dechets sont a attendre. Il faut donc produire plus de telephone que ceux qui va etre vendu.
Au vu des specs du telephone et des volumes, il est probable que la BOM d'un tel telephone soit aux alentours de 400$. Tu as 10$ pour le cout d'assemblage, probablement une moyenne de 50$ pour la livraison international par Fedex, dhl, whatever. Le reste tu vas pouvoir le separer entre indiegogo, tes developpeurs, tes designers et le marketing. Pour simplifier, disons que Indiegogo prend 2m$ (7% du total). Il reste donc pour les modeles a 600$, 140$ par telephone et 370$ pour les modeles a 830$.
En faisant 40000 unites, avec 5000 a 600$, il reste 16 millions de dollar pour developper ton telephone. Le cout moyen d'un developeur est souvent estime entre 120000 et 150000$ par an. Ca donne donc de quoi payer aux alentours de 120 developpeurs sur un an. Comme il faut se laisser un peu de marge pour reinvestir et gerer la casse en cas de probleme, il est probable que cela couvre une centaine de personnes pendant un an… ou 50 pendant deux ans. Ce qui est a peu de chose les chiffres attendus pour le developpement d'un telephone (Jolla est a peu pret de la meme taille).
C'est sur, le test unitaire avec couverture de code, c'est utile. Mais ce n'est pas une balle d'argent qui change la face du monde. Ca aide, des fois… Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests (quel appel systeme peut echouer, quels sont les valeurs de retour acceptable, …). Quand tu commences a devoir tester des interfaces graphiques, ca tombe encore plus bas. Tu peux comparer les pixels de sortie. Mais si le probleme est frame drop dans une animation pilotee par un developpeur, tu vas avoir beaucoup de mal a le detecter. Sans compter les problemes entre les differentes version de drivers qui fait que au final, ton test unitaire devient en pratique un test d'integration sur plusieurs millions de ligne de code…
Au final, avoir une communaute de testeur qui a l'oeil est rapporte les problemes clairement et rapidement a plus de valeur qu'une suite de tests (Ce qui ne veut pas dire qu'on peut s'en passer). Pour faire simple, le meilleur test, c'est eat your own dog food !
Travail/contribution upstream des patchs pour Qt, Gtk, … avec détection au runtime, afin qu'un soft Qt/Gtk/EFL déjà compilé puisse tourner sous Wayland ou Mir.
GTK et Qt sont calculés pour supporter plusieurs backend sans avoir à recompiler les programme. A priori, on aura pas à recompiler les programmes pour faire tourner sous Wayland, X11 ou même Mir.
Je ne vais parler que pour les EFL, car c'est ce que je connais. Les porter sur un nouveau backend, se fait tres rapidement. En une semaine, tu as un truc qui pousse des pixels a l'ecran (Le port initial de Wayland a literalement pris 2 jours pour avoir une fenetre qui s'affiche a l'ecran avec le bon contenu).
Mais et c'est la que commence les joyeusetes, si tu veux un port efficace, tu dois rajouter de plus en plus de chose. Support du double et triple buffer, mise a jour partiel de l'ecran, support des sub-surface, minimisation des discussion entre le client et le serveur, suivit des changements upstream, … Et ca, c'est de la maintenance qui occupe une personne presque a plein temps depuis un an ou deux (Pour X, meme apres 10 ans, le backend EFL recoit toujours des ameliorations). Ca, ca a un cout. Et il faut soit des personnes motives, soit qu'une societe paye une personne pour le faire.
Une strategie de fire and forget permet d'avoir une demo rapidement qui marche, mais ne permet pas du tout d'avoir une solution competitive. Cela veut dire que les toolkits utilisaient sur une tel plateforme seront plus lent, plus lourd et plus consommateur d'energie que si ils etaient utilise dans un environnement ou l'upstream fait la maintenance.
Ca fait plus de dix ans que je suis developpeur et j'ai fait un certain nombre d'entretiens aussi bien en tant que candidats qu'employeurs.
Au final, je pense que la methode "californienne" cree un biais sur les candidats potentiels et ce biais n'a rien a voir avec leur competence, mais uniquement sur leur profil psychologique. Elle favorise les gens qui sont capable de sortir un jugement rapide (moins d'une heure pour trouver une solution a un probleme complex) sur un probleme donne. Or pour avoir rencontre un certain nombre de personne tres tres doue en informatique, aucun, mais alors absolument aucun, ne passera un tel test haut la main, car il leur faut un temps de reflexion.
Ce n'est pas pour rien qu'on dit qu'il faut reecrire 3 fois un programme pour arriver a la bonne solution ! Mais l'avantage d'une telle selection, c'est que si tous les membres de l'equipe ont la meme maniere de penser, cela facilite grandement la gestion des ressources humaines et permet d'avoir une equipe qui va facilement et rapidement dans la meme direction… De maniere symetrique, cela rend plus complique toute remise en question !
Je ne pense pas que ce soit un vrai probleme dans une culture de startup ou l'objectif est d'aller vite dans une direction et ou la remise en question est assure par le marche et une faillite de la societe. Mais cela peut etre plus problematique dans la societe francaise, ce qui explique probablement les differences des entretiens.
Apres a la sortie d'ecole, c'est tout de meme difficile de faire parler un candidat de ses experiences passees pour l'evaluer sans tomber dans l'approche scolaire avec une "soutenance" d'algo/developpement… Au final, recruter pour un stage a l'avantage de vraiment donner l'occasion de connaitre la personne et d'avoir une meilleur vision de ses capacites sans trop compliquer la vie de la societe si ca se passe mal (theoriquement le travail d'un stagiaire ne doit pas etre crucial pour l'entreprise).
OpenGL, peut très bien être utilisé pour accélérer la 2D, c'est d'ailleurs très utilisé pour ça par les compositeurs sous X.
C'est bien parce qu'on n'a pas le choix. Mais on torture franchement cette API et son modele de rendu pour faire de la 2D efficace avec. C'est a la limite du supplice chinois, j'aimerais pas etre a sa place !
De ce que j'ai cru comprendre, Mir implémente (ou va implémenter ?) un scenegraph générique en interne pour les shells basiques tout en fournissant une interface pour permettre au shell d'implémenter son propre scenegraph s'il le souhaite (ce qui sera le cas avec Unity 8). Je ne sais pas si ça peut t'aider dans ta réflexion :-)
Vu les differences entre les API des scenegraph de Qt et des EFL, j'ai bien du mal a voir comment ils vont pouvoir faire un truc generique de ce cote la. Semble etre une approche bien complique.
avait une approche agressive ;)
Depuis l'annonce on voit bien qu'ils ont essayé d'arrondir les angles. Trop tard ou pas, c'est un autre sujet.
Je considere agressif une approche qui consiste a faire :
- un code dump
- calomnier des projets developpes par la communaute
- forcer les developpeurs a ceder leur droit pour leur permettre de faire du proprio
- faire des declarations peremtoires en lieu et place des developpeurs de logiciel libre dans lesquel Ubuntu ne contribue pas
- faire croire que ce qui est fait, est fait pour des raisons techniques et ne pas etre franc sur ses objectifs reels (aka controle complet d'une stack Linux comme Android)
Je ne vois pas trop ce qui s'est ameliore depuis le lancement public du projet, a part peut etre la correction des idioties concernant Wayland dans leur Wiki.
Actuellement SurfaceFlinger passe par la 3D, le rendu 2D n'est plus supporté par Google, seul les fabriquants remettent en place celui-ci pour des raisons de coûts de développement.
Pas pour des questions de cout de developpement, pour des questions d'economies de batterie. L'accelerateur 2d consomme un ordre de grandeur moins que l'accelerateur 3d. Sans compter que etant une unite separe celui-ci n'impacte pas les performances lorsque le compositing fonctionne. Son absence peut se remarquer assez facilement, car le telephone se met a lagguer des qu'il y a un layer transparent au dessus. Exemple probable, le dernier LG permet de prendre des notes en transparence sur les applications. Mais des que tu as ce layer transparent, le telephone ne tiens plus du tout les 60fps. C'est donc assez flagrant comme probleme, meme sur les telephones de derniere generation.
Dire que Wayland est mieux par ce que c'est développé par d'autres que Google, c'est tiré par les cheveux. Wayland est un gros mangeur de ressources et surtout de batterie, pas besoin de benchmark il suffit de regarder la gestion du flip des images dans le code. Ou encore de voir qu'en mode SHM (seul mode disponible sur des petits processeurs), il est impossible d'accéder directement à la mémoire vidéo et donc d'avoir des copies de mémoire. Je sais que c'est pour des raisons de sécurité, mais des fois il faut chercher d'autres solutions.
Non, je dis que Wayland est developpe par un certain nombre d'individu travaillant pour un large eventail de societe avec des objectifs divers. Cela conduit forcement a realiser quelque de chose de plus efficace et generique.
Alors le role d'un compositeur, que ce soit X ou Wayland ou quelqu'il soit dont le but est de faire du multi-application ne peut pas se permettre de donner acces directement a la memoire. Si tu veux acceder directement a la memoire, tu fais ton application sur le frame buffer.
Maintenant ton hardware n'est pas si limite. 400Mhz et 256MB, c'est plutot dans la categorie luxueux pour moi ! On est pas loin de pouvoir faire tourner un desktop complet avec tout ca ;-) Je suis meme pres a parie que tu as une unite d'acceleration 2D ou au moins la gestion de plusieurs plan graphique. Largement de quoi faire tourner un Wayland. Il te manque probablement un driver KMS/DRM pour l'allocation des buffers. Et il n'y a rien qui force dans Wayland a avoir une implementation 3D pour travailler sur des buffers video. Tu peux alors directement alouer des buffer hardware et faire une implementation derriere en soft. La derniere fois que j'avais regarde ce scenario, on devait pouvoir s'en sortir en reutilisant une toute petite partie de EGL. Enfin tout depend apres du nombre d'application a gerer, mais tu dois pas en avoir beaucoup en simultanee vu le materiel, donc laisser Wayland leur donner a chacune un layer graphique doit etre le plus efficace.
Au final, le plus couteux sera la vitesse du backend software de ton toolkit graphique et DirectFB n'est pas bon de ce cote la. Bien entendu, si tu ne veux pas faire du multi application, mais juste avoir des fenetres dans une seule application. Pas la peine de t'ennuyer avec tout ca. Tu prend juste le framebuffer et roule avec les EFL. Peut etre un backend specifique pour tirer partie de l'acceleration 2D, si elle est un minimum utile. Et la, tu auras la solution la plus efficace et versatile.
Ma question était : est-ce que ce support devra être implémenté séparément dans chaque compositeurs Wayland ?
Le support de ces divers drivers proprio n'est pas un code aussi complexe que tu le laisses entendre et encore moins un gros morceau de code. C'est juste de l'allocation de buffer et configuration des sorties, that's it ! Ca finira probablement dans une bibliotheque commune tout de meme, parce que les developpeurs sont faineant, mais pas vraiment parce que c'est un code complique ou toolkit dependant.
Il y a un compositeur Mir que tout le monde est sensé utilisé en rajoutant juste la partie Shell.
Mais biensur ! Donc je vais creer plein de fenetre supplementaire qui ne serve a rien pour mes menus, mon shelf et tout ce qui compose mon desktop. En terme d'optimisation, on repassera. La plus part des toolkits moderne ont deja un scenegraph et son capable de mettre toutes ces ressources graphiques dans le meme scenegraph au lieu d'etre force dans des fenetres separees. Bien entendu, ca aide…
Sans compter que l'optimisation d'un scene graph, ca prend du temps et demande beaucoup d'experience avant d'avoir le niveau de performance necessaire. C'est sur on peut tout balancer a OpenGL et croire au pere noel. Mais si on veut des perfs, vaut mieux faire un peu de boulot avant. Je peux te prendre le paris que le scenegraph de Mir se fait juste enterrer par celui d'Enlightenment (meme probablement celui de Weston aussi) et maintenant va donc me justifier que je fairais mieux de l'utiliser.
Contrairement a ce que tu penses les roues sont deja en place. C'est une competition de Formule 1 ou Wayland decrit les contraintes des voitures. Il n'y a pas de reinvention, juste un assemblage de piece deja existante et en general ce nouvel assemblage aide aussi a pousser a l'optimisation de la version X. D'ailleur Mir utilise les meme pieces de maniere general, sauf qu'il ne respecte pas les regles et a une approche aggressive envers la communaute.
Tu devrais t'intéresser à la communauté Ubuntu avant de porter de tels jugements ;)
Je parlais de la communaute des developpeurs, pas des trolleurs ! ;-)
Il me semble que KDE et Gnome ont eux aussi prévu d'utiliser un compositeur système pour gérer les sessions, ce qui implique de lancer le compositeur en question bien avant l'écran de login.
Le compositeur systeme est quelque chose encore en debat. Il introduit des problemes de performance qu'on ne sait pas encore comment resoudre. Le principal probleme etant sur les inputs. Toutes les entrees/sorties devant etre controle par le compositeur systeme. Ca rajoute un process qui doit etre reveille et traverse avant, soit de pouvoir envoyer une action d'un peripherique vers le compositeur du desktop en cour, soit de pouvoir envoyer un buffer a l'ecran. Cela a un impact non negligeable et pas forcement utile au final. Pourquoi faut-il payer le prix chere pour si peu ?
Pour cette raison, entre autre, j'ai du mal comprendre pourquoi Wayland demande à tout le monde de ré-implémenter son propre compositeur. De ce point de vue, l'approche Mir qui consiste à séparer l'implémentation du bureau du serveur d'affichage avec une couche de glue entre les deux me parait être conceptuellement plus intelligente. C'est certes plus proche de l'infrastructure X actuelle, mais ça permet de factoriser beaucoup de code entre les DE (car oui, Mir en lui même n'est absolument pas spécifique à Unity, Canonical à même proposé son aide pour porter les autres shells).
Tout le monde reimplemente deja son propre compositeur. KWin, Compiz, Enlightenment, … Tous les desktops un peu moderne ont deja se code. Et pour certain sont plus rapide que le code du compositeur se trouvant dans X ! Chacun utilise aussi un toolkit different et donc il n'y a que tres peu de code factorisable.
Le but de Weston est de fournir une implementation de reference pour Wayland, mais aussi de fournir un ensemble de bibliotheque agnostique du compositeur et de les maintenir pour le benefice de tout le monde. L'approche de Wayland permet d'avoir le maximum de performance possible tout en factorisant le code qui peut l'etre.
Mir de son cote ne travaillant pas du tout avec la communaute, il n'y a aucun travail reel de factorisation. C'est juste un decoupage arbitraire entre Unity et Mir qui est mis en place. Sans compter que je ne pense pas qu'ils ont les connaissance de l'ensemble de la communaute travaillant sur Wayland pour faire un compositeur aussi performant.
Par exemple, si je ne m'abuse, quand les pilotes proprios vont supporter Mir, c'est bien chaque compositeur Wayland qui va devoir se rendre compatible indépendamment.
Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios. Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement, mais Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.
Bref, je suis assez pessimiste sur l'avenir de tout ça et j'ai besoin d'être rassuré par des gens qui s'y connaissent.
T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux… sans grand interet pour la communaute !
A ce que j'ai compris Canonical vise ubuntu touch en priorité pour MIR. Et donc ne tombe pas encore en concurrence avec wayland car les perfs de wayland en embarqué sont lamentables. Je ne connais pas l'implémentation de MIR mais cela ne peut pas être pire que wayland (DirectFB a encore de longs jours devant lui).
Serieux ! Faut se documenter avant de dire de si grosse betise ! Wayland est aujourd'hui plus performant que Mir et utilise depuis longtemps dans l'embarque. La difficulte est de supporter toutes les extentions necessaire a une experience desktop complete. Je ne sais pas d'ou tu sors cette idee que les perfs de Wayland en embarque sont lamentable, mais techniquement le modele de rendu de Wayland vise a minimiser les phases de rendu en mode composite pour privilegie les rendu fullscreen et par layer. C'est la combinaison ideal pour obtenir le maximum de performance du hardware. En gros, Wayland permet d'atteindre les performances maximum du hardware, ce que ne permet pas encore Mir.
Quand a DirectFB, a part sur des set top box completement ferme, personne ne l'utilise pour une bonne raison, ca n'apporte pas de solution propre et efficace pour resoudre les problemes graphiques rencontre par Linux. D'ailleur dans la pratique DirectFB est maintenant plus lent que pas mal d'alternative, c'est pour ca que le backend DirectFB des EFL est abandonne.
Pour ce qui est de SurfaceFlinger celui-ci est aussi dédié à l'embarqué, du moins dans les premières versions d'Android. [..] Maintenant il faut à tout prix de l'accélération 3D, et à part sur les PCphones, il est plus possible de l'utiliser.
A ma connaissance SurfaceFlinger ne necessite pas de l'acceleration 3d, mais juste un minimum d'acceleration 2d. C'est une des raisons pour lesquel la plus part des chipset ARM aujourd'hui arrive avec des unites dedies basse consomation pour le compositing. Et c'est une bonne chose, car cela ouvre un chemin d'optimisation supplementaire sur ces hardware la. Et faire du compositing en soft, c'est drole qu'en on est sur des basses resolutions, mais en HD, tu vas juste tuer ta batterie !
Apres Android a ete ecris par des gens qui ne connaissait pas Linux et n'ont jamais interagit avec la communaute. Wayland est techniquement plus performant que SurfaceFlinger. La preuve en est que le developpement par les methodes du logiciel libre donne sur le long terme de meilleur resultat technique, par contre sur le court terme prendre des raccourcis aide a arriver sur le marche plus vite. Et SurfaceFlinger est dedie au haut de gamme de l'embarque pour permettre a Google de prendre la main rapidement et avant tout le monde sur tous les marches ou il peut afficher de la pub.
Tu vas pas nous la refaire celle la ! A part Xterm, il n'y a aucun toolkit qui utilise encore les primitives de X aujourd'hui. Faire de la compression sur des deltas comme on fait de la video sera plus performant que X. D'ailleur, c'est ce que fait NX pour rendre X utilisable… Je dis ca, je dis rien !
Oui, mais non, XWayland est aujourd'hui plus performant dans certain cas et identique dans les autres que X. La raison des lenteurs de XMir etant le manque d'un certain nombre de fast path assez obligatoire.
Petite precision concernant Enlightenment. La version git actuel supporte les clients Wayland. Il est donc possible d'utiliser des applications uniquement ecrite pour Wayland depuis une session X avec Enlightenment 18. Ce mode est utile pour tester le protocol, mais aussi absolument necessaire pour supporter les drivers proprietaires qui ne fournissent pas ce qu'il faut pour faire une implementation Wayland sans X.
Les travaux sont en cour pour faire de Enlightenment un compositeur Wayland sans avoir besoin de X pour les drivers libre. Cela ne sera disponible que dans Enlightenment 19. La sortie de Enlightenment 18 devant arriver d'ici quelques mois, une fois les EFL 1.8 release. Si tout se passe comme prevu, on devrait avoir un support complet de Wayland et avoir une experience similaire a celle que l'on a avec X pour le debut de l'annee prochaine.
Si l'experience est identique, il faut bien voir que Wayland ouvre un certain nombre de possibilite non negligeable a terme et c'est bien la raison pour laquelle tous les desktops libre s'y mettent. Meilleur performance, meilleur securite, meilleur portabilite (surtout dans l'embarque) et plus grande versabilite.
Parce les slots et signaux en C++, c'etait fait pour ? ;-) Ou alors l'obscurantisme des surcharges d'operateurs qui ameliorent grandement la lecture et la localisation d'un bug, d'un memory leak ou d'une perte de performance… Ah, le troll des langages !
Comme toujours un langage n'est bien que si il est maitrise par les personnes qui l'utilisent. Et le C++ n'est absolument pas une silver bullet dans ce domaine ! J'ai trop souvent vu des horreurs sur des projets industriels justement parce que fait en C++ par des architectes qui ne codent pas, mais qui voulait justifier leur job… Au moins en C, ils peuvent plus difficilement s'exprimer :-D Il n'y a guere que dans le logiciel libre que l'utilisation du C++ donne des resultats vraiment positif (en terme de fonctionnalite en tout cas) avec KDE, mais c'est aussi peut etre parce que chez GNOME ca fait dix ans qu'ils bossent a supprimer des fonctions !
C'est plutot la stabilite API/ABI des bibliotheques utilisaient par tes logiciels proprio. Un certain nombre de projet, comme GNOME, Boost, XUL par exemple, ont beaucoup de mal a maintenir la stabilite de leur API/ABI entre deux releases ce qui casse les applications qui l'utilisent. C'est un contournement plutot du probleme, car il est je trouve normal et important que les API/ABI des bibliotheques soient stable entre deux releases mineurs et qu'en cas de majeur on puisse avoir une installation en parallele. Mais bon, tous les toolkits n'ont pas compris ca…
Peut etre parce que Mir, c'est Ubuntu only (Va falloir compte le nombre de contribution externe non paye par Ubuntu) alors que Systemd a reussi a avoir le soutien de plusieurs distro et de beaucoup de developpeurs… Apres que tu sois grincheux et que tu n'aimes pas systemd ne va pas en faire une mauvaise solution technique, contrairement a Mir qui est juste une enorme betise (Protocol pas stable, pas de reflexion sur les inputs, la securite et un paquet d'optimisation necessaire pour baisser la conso).
Euh,tu as loupe un gros détails, wayland est base sur de la mise a jour partiel de buffer pour toutes les frames. Plutôt bien adapté pour les codecs vidéo…
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
J'ai juste dis performance. Et en ADSL avec NX (donc en echange de buffer compresse moins efficace que ce que peux faire Wayland), j'ai des performances meilleurs qu'en utilisant X avec des toolkits faisant du Xrender. Et aujourd'hui, la plus part des toolkits ont abandonnees de fait Xrender. Je ne connais pas de cas ou j'ai eu une meilleur utilisation avec Xrender. Bon apres, ca c'est peut etre ameliorer depuis qu'on a tue notre backend, il y a 2 ans, mais les performances ont toujours ete abyssal, en local et en distant.
il vaudra mieux utiliser ssh ou NX (donc X).
NX fait de la compression de buffer tres efficacement qd tu exportes de l'export display et ca marche tres bien pour des terminaux qui n'utilisent pas Xrender. Donc si tu peux utiliser NX, tu pourras utiliser Wayland pour le meme usage.
J'imagine que tu voulais dire l'API de dessin de X ?
Ah ah ah ! Oui :-)
Le texte, c'est aussi dans ton traitement de texte, dans ton tableur, dans ton logiciel de messagerie, dans…
Sauf que dans le cas du traitement de texte, tu vas vouloir avoir un controle tres fin du rendu, et il est peu probable que tu t'appuie sur le serveur graphique. Si tu veux avoir un resultat a peu pres proche de la sortie imprimante et du resultat sur Windows/MacOs, tu veux avoir le meme moteur de rendu… Donc je parie que tu ne passes pas aujourd'hui par XRender.
Sans compter que en terme de performance, c'est du texte que tu veux lire, donc tu n'es pas a vouloir le faire defiler a grande vitesse. Ca implique que au final, tu as des images tres statique avec de petit motion vector. Donc le rendu avec des sous-surfaces qui sont deplace donnera de bonne performance et laissera les choses tres utilisable. Ce sera probablement le cas pour les tableurs et les logiciels de messagerie aussi.
Il n'y a que les terminaux qui on un besoin de performance et de debit reseau reellement.
Mouais, a part pour le cas tres particulier du urxvt qui tourne dans X, je vois pas trop qu'elle application a distance aura un interet a faire ce genre d'usage. J'en reviens a me demander pourquoi pas juste ssh ? Qu'est-ce que tu gagnes a mettre cette complexite dans Wayland.
Bon, apres d'un point de vue theorique, c'est pas forcement si impossible a pousser dans Wayland. Il suffit d'avoir un nouveau type de surface qui serait un buffer juste de texte et que les toolkits soient capable de l'utiliser pour decoreller le texte du reste. Mais bon, je reste tres dubitatif sur l'utilisation de cette technique pour ce requirement.
3) La gestion des fontes, l'article "oublie" de parler de l'extension XRender et de son caches des glyphes, un mécanisme efficace pour avoir des fontes dessinées par le client mais permettant l'affichage de texte en distant en envoyant peu de donnée (beaucoup moins que l'envoi de gros buffers comme Wayland), évidemment ça ne rentre pas dans le parti-pris de l'article donc c'est zappé.
Vu les performances de XRender, je doutes qu'il y ait encore beaucoup de toolkit qui l'utilisent… A part xterm et probablement urxvt, il ne doit meme pas y avoir beaucoup de terminaux qui l'utilisent encore directement.
4) Wayland n'a pas d'API de dessin, certes c'est plus simple mais ça peu aussi être moins efficace en distant: soit on envoi des gros buffers (très consommateurs en bande passante plus qu'un film puisque non compressé!), soit on les compresse mais la compression ça prend du temps donc on ajoute encore de la latence (compression et décompression), dommage la latence est le problème numéro 1 en distant!
Vu l'echec de l'API de dessin de Wayland, c'est une bonne chose que de ne pas mettre un truc inutile dedans et de completement le decoreller en se reposant entre autre chose sur OpenGL/EGL.
7) L'article décris X comme étant synchrone alors qu'XCB est asynchrone, mettre sur le dos d'X la lenteur des toolkits a passé d'XLib à XCB..
Est-ce qu'il y a un seul toolkit qui utilise juste xcb ? La reponse est non pour une seule raison, il n'y a pas de support de XCB pour OpenGL de disponible avec la majorite des drivers (En fait, je ne sais meme pas si il y en a un qui le propose). Sur le papier xcb, c'est bien, mais au final, tu dois de toute facon avoir xlib, donc les toolkits se tappent une double stack qui n'apporte pas suffisament pour justifier l'effort.
8) Pour ce qui est d'être meilleur qu'X a distance, euh ça dépend, pour afficher quoi?
Pas pour afficher du texte à distance en tout cas, cf (3)!
J'avoue que j'ai du mal a comprendre cet objectif, si je veux juste du texte a distance, j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
Ca ne marche que lorsque l'inflation est suivi par une croissance economique pour permettre l'augmentation des salaires. Si cela n'est pas le cas, ca ruine tout le monde, jeune et vieux. Les seuls qui s'en sortent sont ceux qui sont les plus riche pour qui la perte aura moins d'impact sur leur niveau de vie que sur les autres classes.
Et il n'y aura pas de croissance economique au niveau mondial pour les 20 ans a venir. C'est juste quelque chose d'idiot que de l'attendre et d'avoir un systeme calibre pour une tel situation. Il vaut mieux planifier la decroissance et le chomage de masse si on veut etre realiste.
Pour demontrer la decroissance a venir, c'est assez simple. La croissance economique passe est lie tres majoritairement a l'augmentation de notre consomation d'energie, pas au progres. Cela veut dire que si notre consomation d'energie stagne… c'est la crise ! D'ailleur on est globalement sur un palie depuis 2005. Et si elle commence a diminuer, et bien le progres ne pourra pas compenser les pertes, nous nous retrouverons donc en decroissance. La production mondiale de petrole devant commencer a descendre a partir de 2018/2020, je vous laisse en tirer les conclusions qui s'imposent.
Ah, et aussi, l'argent ne payant que les hommes, l'optimisation automatique d'un tel systeme veut qu'on supprime au maximum les hommes de tous les process. C'est a dire IA et robotique vont continuer a remplacer massivement les emplois. Il est temps d'abandonner le reve mythique du plein emploi et de revoir en profondeur notre systeme economique.
L'inflation sans croissance, c'est un peu la strategie de l'echec ou celle de cacher la misere sous les tapis. L'inflation n'augmente pas le pouvoir d'achat reel des individus. Elle fait certe disparaitre les dettes passees, mais aussi les gains passes. Une joli strategie de cigale pour ruiner les fourmies !
A terme, l'inflation sans croissance, c'est juste un bain de sang. République de Weimar en est un bon exemple de resultat.
Ce qui est fondamental, c'est surtout de calibrer notre systeme pour une baisse de la croissance permanente dans les 20 prochaines annees, l'augmentation du nombre de retraites et du nombre de chomeurs. Sans un systeme resilient a ces parametres, ce sera la guerre civile. Et quand je dis resilient, je ne parle pas de dette ou de securite social, je parle d'un systeme dans lequel les gens acceptent de vivre sans aller en guerre ! Parce que aujourd'hui, c'est fondamentalement ca qui nous pend au nez.
D'un point de vue historique, on voit que les problemes serieux ont commence a pointer leur nez au debut des annees 70. Peut etre que le ralentissement de la croissance des approvisionnements en petrole et gaz pas chere a eu un impact. Peut etre que l'informatisation et la robotisation a reduit la necessite d'employer des grandes quantites de travailleurs pour boulonner et visser des voitures. Peut etre que notre comprehension en tant que civilisation de ce qu'a ete notre progres ces derniers siecles est completement fausse par le message des theories economiques d'un temps ou l'espece humaine etait dix fois moins nombreux et ou les apport externe pouvait etre considere comme infini.
Notre premier probleme, c'est d'avoir des theories economique qui prendre en compte les limites du monde dans lequel on vit ! Si on continue de suivre les theses qui ont deux siecles et pensent que notre pouvoir d'achat est uniquement lie a l'effort humain fournit (L'argent ne sert aujourd'hui que a payer des etres humain), on pourra imprimer tous les billets qu'on veut, le systeme s'ecroulera au final.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
C'est plus l'exception que la regle. Avoir des appels systemes qui ne font jamais d'erreur, avoir de la memoire infini pour ne jamais faire un echec lors d'une allocation, ne pas avoir de corruption de ses systemes de stockage, … Il y a toujours des erreurs, faut juste faire en sorte que le systeme se degrade pas trop.
Tester le cas qui marche, oui. Tester quand une partie du materiel a chaud, froid, recoit un rayon cosmique, … ca devient moins probable. Sans compter que le materiel moderne est tres tres fortement asynchrone et multi cpu, ce qui introduit des races conditions que tu vas avoir un mal de fou a voir sur une suite de test unitaire.
Une suite de tests limite les regressions, mais pas les bugs.
[^] # Re: Trendeu myons ?!
Posté par cedric . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 10.
Non, c'est plutot realiste comme budget. C'est a peu pres ce que ca coute de developper un telephone. La partie la plus difficile dans la fabrication d'un telephone (ou d'ailleur de tout materiel hardware) est de sourcer les composants.
Quand tu t'appels Samsung, c'est facile, tu es gros et tout le monde veut te vendre un truc. Quand tu es petit, il te faut sortir une grande quantite de cash et payer d'embler pour 10000 ecrans pour en securiser l'approvisionnement. Et tu repetes l'histoire pour tous tes composants. Tu n'as encore rien produit et tes ingenieurs hardware travail pour l'instant sur un prototype avec des composants qu'ils esperent avoir que tu as deja depenser 80% du cout de ta BOM. Une fois que tous les composants sont la, tu essayes de valider un premier run. Si tu as de la chance, tu n'as pas de souci et tu peux continuer. En general, tu as des ajustement a faire et tu refais un tour. Dans le pire des cas, tu dois changer quelques composants et tu tentes de revendre ceux que tu ne veux pas utiliser.
A ce moment la, tu peux commencer a lancer ta production. Va falloir aller voir dans l'usine et verifier que ce qui sort est de qualite et passe les tests. La aussi, il y a de la perte et plus tu fais un truc cutting edge plus tes couts hardware vont monter. Meme si les materiaux choisi semble resistant, il est probable qu'il n'y ait pas d'usine qui ait l'habitude de travailler avec, donc des dechets sont a attendre. Il faut donc produire plus de telephone que ceux qui va etre vendu.
Au vu des specs du telephone et des volumes, il est probable que la BOM d'un tel telephone soit aux alentours de 400$. Tu as 10$ pour le cout d'assemblage, probablement une moyenne de 50$ pour la livraison international par Fedex, dhl, whatever. Le reste tu vas pouvoir le separer entre indiegogo, tes developpeurs, tes designers et le marketing. Pour simplifier, disons que Indiegogo prend 2m$ (7% du total). Il reste donc pour les modeles a 600$, 140$ par telephone et 370$ pour les modeles a 830$.
En faisant 40000 unites, avec 5000 a 600$, il reste 16 millions de dollar pour developper ton telephone. Le cout moyen d'un developeur est souvent estime entre 120000 et 150000$ par an. Ca donne donc de quoi payer aux alentours de 120 developpeurs sur un an. Comme il faut se laisser un peu de marge pour reinvestir et gerer la casse en cas de probleme, il est probable que cela couvre une centaine de personnes pendant un an… ou 50 pendant deux ans. Ce qui est a peu de chose les chiffres attendus pour le developpement d'un telephone (Jolla est a peu pret de la meme taille).
Et oui, faire un gadget, c'est pas gratuit !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par cedric . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
C'est sur, le test unitaire avec couverture de code, c'est utile. Mais ce n'est pas une balle d'argent qui change la face du monde. Ca aide, des fois… Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests (quel appel systeme peut echouer, quels sont les valeurs de retour acceptable, …). Quand tu commences a devoir tester des interfaces graphiques, ca tombe encore plus bas. Tu peux comparer les pixels de sortie. Mais si le probleme est frame drop dans une animation pilotee par un developpeur, tu vas avoir beaucoup de mal a le detecter. Sans compter les problemes entre les differentes version de drivers qui fait que au final, ton test unitaire devient en pratique un test d'integration sur plusieurs millions de ligne de code…
Au final, avoir une communaute de testeur qui a l'oeil est rapporte les problemes clairement et rapidement a plus de valeur qu'une suite de tests (Ce qui ne veut pas dire qu'on peut s'en passer). Pour faire simple, le meilleur test, c'est eat your own dog food !
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Je ne vais parler que pour les EFL, car c'est ce que je connais. Les porter sur un nouveau backend, se fait tres rapidement. En une semaine, tu as un truc qui pousse des pixels a l'ecran (Le port initial de Wayland a literalement pris 2 jours pour avoir une fenetre qui s'affiche a l'ecran avec le bon contenu).
Mais et c'est la que commence les joyeusetes, si tu veux un port efficace, tu dois rajouter de plus en plus de chose. Support du double et triple buffer, mise a jour partiel de l'ecran, support des sub-surface, minimisation des discussion entre le client et le serveur, suivit des changements upstream, … Et ca, c'est de la maintenance qui occupe une personne presque a plein temps depuis un an ou deux (Pour X, meme apres 10 ans, le backend EFL recoit toujours des ameliorations). Ca, ca a un cout. Et il faut soit des personnes motives, soit qu'une societe paye une personne pour le faire.
Une strategie de fire and forget permet d'avoir une demo rapidement qui marche, mais ne permet pas du tout d'avoir une solution competitive. Cela veut dire que les toolkits utilisaient sur une tel plateforme seront plus lent, plus lourd et plus consommateur d'energie que si ils etaient utilise dans un environnement ou l'upstream fait la maintenance.
[^] # Re: Algorithmique
Posté par cedric . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 9.
Ca fait plus de dix ans que je suis developpeur et j'ai fait un certain nombre d'entretiens aussi bien en tant que candidats qu'employeurs.
Au final, je pense que la methode "californienne" cree un biais sur les candidats potentiels et ce biais n'a rien a voir avec leur competence, mais uniquement sur leur profil psychologique. Elle favorise les gens qui sont capable de sortir un jugement rapide (moins d'une heure pour trouver une solution a un probleme complex) sur un probleme donne. Or pour avoir rencontre un certain nombre de personne tres tres doue en informatique, aucun, mais alors absolument aucun, ne passera un tel test haut la main, car il leur faut un temps de reflexion.
Ce n'est pas pour rien qu'on dit qu'il faut reecrire 3 fois un programme pour arriver a la bonne solution ! Mais l'avantage d'une telle selection, c'est que si tous les membres de l'equipe ont la meme maniere de penser, cela facilite grandement la gestion des ressources humaines et permet d'avoir une equipe qui va facilement et rapidement dans la meme direction… De maniere symetrique, cela rend plus complique toute remise en question !
Je ne pense pas que ce soit un vrai probleme dans une culture de startup ou l'objectif est d'aller vite dans une direction et ou la remise en question est assure par le marche et une faillite de la societe. Mais cela peut etre plus problematique dans la societe francaise, ce qui explique probablement les differences des entretiens.
Apres a la sortie d'ecole, c'est tout de meme difficile de faire parler un candidat de ses experiences passees pour l'evaluer sans tomber dans l'approche scolaire avec une "soutenance" d'algo/developpement… Au final, recruter pour un stage a l'avantage de vraiment donner l'occasion de connaitre la personne et d'avoir une meilleur vision de ses capacites sans trop compliquer la vie de la societe si ca se passe mal (theoriquement le travail d'un stagiaire ne doit pas etre crucial pour l'entreprise).
[^] # Re: Et compiz ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 4.
C'est bien parce qu'on n'a pas le choix. Mais on torture franchement cette API et son modele de rendu pour faire de la 2D efficace avec. C'est a la limite du supplice chinois, j'aimerais pas etre a sa place !
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 4.
Vu les differences entre les API des scenegraph de Qt et des EFL, j'ai bien du mal a voir comment ils vont pouvoir faire un truc generique de ce cote la. Semble etre une approche bien complique.
Je considere agressif une approche qui consiste a faire :
- un code dump
- calomnier des projets developpes par la communaute
- forcer les developpeurs a ceder leur droit pour leur permettre de faire du proprio
- faire des declarations peremtoires en lieu et place des developpeurs de logiciel libre dans lesquel Ubuntu ne contribue pas
- faire croire que ce qui est fait, est fait pour des raisons techniques et ne pas etre franc sur ses objectifs reels (aka controle complet d'une stack Linux comme Android)
Je ne vois pas trop ce qui s'est ameliore depuis le lancement public du projet, a part peut etre la correction des idioties concernant Wayland dans leur Wiki.
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 7.
Pas pour des questions de cout de developpement, pour des questions d'economies de batterie. L'accelerateur 2d consomme un ordre de grandeur moins que l'accelerateur 3d. Sans compter que etant une unite separe celui-ci n'impacte pas les performances lorsque le compositing fonctionne. Son absence peut se remarquer assez facilement, car le telephone se met a lagguer des qu'il y a un layer transparent au dessus. Exemple probable, le dernier LG permet de prendre des notes en transparence sur les applications. Mais des que tu as ce layer transparent, le telephone ne tiens plus du tout les 60fps. C'est donc assez flagrant comme probleme, meme sur les telephones de derniere generation.
Non, je dis que Wayland est developpe par un certain nombre d'individu travaillant pour un large eventail de societe avec des objectifs divers. Cela conduit forcement a realiser quelque de chose de plus efficace et generique.
Alors le role d'un compositeur, que ce soit X ou Wayland ou quelqu'il soit dont le but est de faire du multi-application ne peut pas se permettre de donner acces directement a la memoire. Si tu veux acceder directement a la memoire, tu fais ton application sur le frame buffer.
Maintenant ton hardware n'est pas si limite. 400Mhz et 256MB, c'est plutot dans la categorie luxueux pour moi ! On est pas loin de pouvoir faire tourner un desktop complet avec tout ca ;-) Je suis meme pres a parie que tu as une unite d'acceleration 2D ou au moins la gestion de plusieurs plan graphique. Largement de quoi faire tourner un Wayland. Il te manque probablement un driver KMS/DRM pour l'allocation des buffers. Et il n'y a rien qui force dans Wayland a avoir une implementation 3D pour travailler sur des buffers video. Tu peux alors directement alouer des buffer hardware et faire une implementation derriere en soft. La derniere fois que j'avais regarde ce scenario, on devait pouvoir s'en sortir en reutilisant une toute petite partie de EGL. Enfin tout depend apres du nombre d'application a gerer, mais tu dois pas en avoir beaucoup en simultanee vu le materiel, donc laisser Wayland leur donner a chacune un layer graphique doit etre le plus efficace.
Au final, le plus couteux sera la vitesse du backend software de ton toolkit graphique et DirectFB n'est pas bon de ce cote la. Bien entendu, si tu ne veux pas faire du multi application, mais juste avoir des fenetres dans une seule application. Pas la peine de t'ennuyer avec tout ca. Tu prend juste le framebuffer et roule avec les EFL. Peut etre un backend specifique pour tirer partie de l'acceleration 2D, si elle est un minimum utile. Et la, tu auras la solution la plus efficace et versatile.
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 8.
Le support de ces divers drivers proprio n'est pas un code aussi complexe que tu le laisses entendre et encore moins un gros morceau de code. C'est juste de l'allocation de buffer et configuration des sorties, that's it ! Ca finira probablement dans une bibliotheque commune tout de meme, parce que les developpeurs sont faineant, mais pas vraiment parce que c'est un code complique ou toolkit dependant.
Mais biensur ! Donc je vais creer plein de fenetre supplementaire qui ne serve a rien pour mes menus, mon shelf et tout ce qui compose mon desktop. En terme d'optimisation, on repassera. La plus part des toolkits moderne ont deja un scenegraph et son capable de mettre toutes ces ressources graphiques dans le meme scenegraph au lieu d'etre force dans des fenetres separees. Bien entendu, ca aide…
Sans compter que l'optimisation d'un scene graph, ca prend du temps et demande beaucoup d'experience avant d'avoir le niveau de performance necessaire. C'est sur on peut tout balancer a OpenGL et croire au pere noel. Mais si on veut des perfs, vaut mieux faire un peu de boulot avant. Je peux te prendre le paris que le scenegraph de Mir se fait juste enterrer par celui d'Enlightenment (meme probablement celui de Weston aussi) et maintenant va donc me justifier que je fairais mieux de l'utiliser.
Contrairement a ce que tu penses les roues sont deja en place. C'est une competition de Formule 1 ou Wayland decrit les contraintes des voitures. Il n'y a pas de reinvention, juste un assemblage de piece deja existante et en general ce nouvel assemblage aide aussi a pousser a l'optimisation de la version X. D'ailleur Mir utilise les meme pieces de maniere general, sauf qu'il ne respecte pas les regles et a une approche aggressive envers la communaute.
Je parlais de la communaute des developpeurs, pas des trolleurs ! ;-)
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 7.
Le compositeur systeme est quelque chose encore en debat. Il introduit des problemes de performance qu'on ne sait pas encore comment resoudre. Le principal probleme etant sur les inputs. Toutes les entrees/sorties devant etre controle par le compositeur systeme. Ca rajoute un process qui doit etre reveille et traverse avant, soit de pouvoir envoyer une action d'un peripherique vers le compositeur du desktop en cour, soit de pouvoir envoyer un buffer a l'ecran. Cela a un impact non negligeable et pas forcement utile au final. Pourquoi faut-il payer le prix chere pour si peu ?
Pour plus de lecture sur le sujet, je conseille cet excellent blog : https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-system-compositors/ .
Tout le monde reimplemente deja son propre compositeur. KWin, Compiz, Enlightenment, … Tous les desktops un peu moderne ont deja se code. Et pour certain sont plus rapide que le code du compositeur se trouvant dans X ! Chacun utilise aussi un toolkit different et donc il n'y a que tres peu de code factorisable.
Le but de Weston est de fournir une implementation de reference pour Wayland, mais aussi de fournir un ensemble de bibliotheque agnostique du compositeur et de les maintenir pour le benefice de tout le monde. L'approche de Wayland permet d'avoir le maximum de performance possible tout en factorisant le code qui peut l'etre.
Mir de son cote ne travaillant pas du tout avec la communaute, il n'y a aucun travail reel de factorisation. C'est juste un decoupage arbitraire entre Unity et Mir qui est mis en place. Sans compter que je ne pense pas qu'ils ont les connaissance de l'ensemble de la communaute travaillant sur Wayland pour faire un compositeur aussi performant.
Euh non, Wayland s'appuie sur KMS/DRM, rien de folklo la dedans, rien de specifique pour des pilotes proprios. Il est apres possible d'utiliser des implementations differente pour contourner des drivers proprio ou mal goupille, RPi et Android principalement, mais Mir fait exactement la meme chose. Aucune difference technique entre les deux de ce cote la.
T'inquiete pas. Oublie Mir. Change de distro si tu utilises Ubuntu, car ils ne travaillent pas avec la communaute et essaye de construire leur propre ecosysteme controle comme Android. Ils sont en marche pour faire un Ubuntu/Linux… sans grand interet pour la communaute !
[^] # Re: Waylands et Mir ?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Serieux ! Faut se documenter avant de dire de si grosse betise ! Wayland est aujourd'hui plus performant que Mir et utilise depuis longtemps dans l'embarque. La difficulte est de supporter toutes les extentions necessaire a une experience desktop complete. Je ne sais pas d'ou tu sors cette idee que les perfs de Wayland en embarque sont lamentable, mais techniquement le modele de rendu de Wayland vise a minimiser les phases de rendu en mode composite pour privilegie les rendu fullscreen et par layer. C'est la combinaison ideal pour obtenir le maximum de performance du hardware. En gros, Wayland permet d'atteindre les performances maximum du hardware, ce que ne permet pas encore Mir.
Quand a DirectFB, a part sur des set top box completement ferme, personne ne l'utilise pour une bonne raison, ca n'apporte pas de solution propre et efficace pour resoudre les problemes graphiques rencontre par Linux. D'ailleur dans la pratique DirectFB est maintenant plus lent que pas mal d'alternative, c'est pour ca que le backend DirectFB des EFL est abandonne.
A ma connaissance SurfaceFlinger ne necessite pas de l'acceleration 3d, mais juste un minimum d'acceleration 2d. C'est une des raisons pour lesquel la plus part des chipset ARM aujourd'hui arrive avec des unites dedies basse consomation pour le compositing. Et c'est une bonne chose, car cela ouvre un chemin d'optimisation supplementaire sur ces hardware la. Et faire du compositing en soft, c'est drole qu'en on est sur des basses resolutions, mais en HD, tu vas juste tuer ta batterie !
Apres Android a ete ecris par des gens qui ne connaissait pas Linux et n'ont jamais interagit avec la communaute. Wayland est techniquement plus performant que SurfaceFlinger. La preuve en est que le developpement par les methodes du logiciel libre donne sur le long terme de meilleur resultat technique, par contre sur le court terme prendre des raccourcis aide a arriver sur le marche plus vite. Et SurfaceFlinger est dedie au haut de gamme de l'embarque pour permettre a Google de prendre la main rapidement et avant tout le monde sur tous les marches ou il peut afficher de la pub.
[^] # Re: Enlightenment
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Tu vas pas nous la refaire celle la ! A part Xterm, il n'y a aucun toolkit qui utilise encore les primitives de X aujourd'hui. Faire de la compression sur des deltas comme on fait de la video sera plus performant que X. D'ailleur, c'est ce que fait NX pour rendre X utilisable… Je dis ca, je dis rien !
[^] # Re: Changement de pilote
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 6.
Oui, mais non, XWayland est aujourd'hui plus performant dans certain cas et identique dans les autres que X. La raison des lenteurs de XMir etant le manque d'un certain nombre de fast path assez obligatoire.
# Enlightenment
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
Petite precision concernant Enlightenment. La version git actuel supporte les clients Wayland. Il est donc possible d'utiliser des applications uniquement ecrite pour Wayland depuis une session X avec Enlightenment 18. Ce mode est utile pour tester le protocol, mais aussi absolument necessaire pour supporter les drivers proprietaires qui ne fournissent pas ce qu'il faut pour faire une implementation Wayland sans X.
Les travaux sont en cour pour faire de Enlightenment un compositeur Wayland sans avoir besoin de X pour les drivers libre. Cela ne sera disponible que dans Enlightenment 19. La sortie de Enlightenment 18 devant arriver d'ici quelques mois, une fois les EFL 1.8 release. Si tout se passe comme prevu, on devrait avoir un support complet de Wayland et avoir une experience similaire a celle que l'on a avec X pour le debut de l'annee prochaine.
Si l'experience est identique, il faut bien voir que Wayland ouvre un certain nombre de possibilite non negligeable a terme et c'est bien la raison pour laquelle tous les desktops libre s'y mettent. Meilleur performance, meilleur securite, meilleur portabilite (surtout dans l'embarque) et plus grande versabilite.
[^] # Re: Are you from the past?
Posté par cedric . En réponse à la dépêche Qt 5.1 est juillet. Évalué à 6.
Parce les slots et signaux en C++, c'etait fait pour ? ;-) Ou alors l'obscurantisme des surcharges d'operateurs qui ameliorent grandement la lecture et la localisation d'un bug, d'un memory leak ou d'une perte de performance… Ah, le troll des langages !
Comme toujours un langage n'est bien que si il est maitrise par les personnes qui l'utilisent. Et le C++ n'est absolument pas une silver bullet dans ce domaine ! J'ai trop souvent vu des horreurs sur des projets industriels justement parce que fait en C++ par des architectes qui ne codent pas, mais qui voulait justifier leur job… Au moins en C, ils peuvent plus difficilement s'exprimer :-D Il n'y a guere que dans le logiciel libre que l'utilisation du C++ donne des resultats vraiment positif (en terme de fonctionnalite en tout cas) avec KDE, mais c'est aussi peut etre parce que chez GNOME ca fait dix ans qu'ils bossent a supprimer des fonctions !
[^] # Re: C'est plus facile de travailler salement…
Posté par cedric . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
C'est plutot la stabilite API/ABI des bibliotheques utilisaient par tes logiciels proprio. Un certain nombre de projet, comme GNOME, Boost, XUL par exemple, ont beaucoup de mal a maintenir la stabilite de leur API/ABI entre deux releases ce qui casse les applications qui l'utilisent. C'est un contournement plutot du probleme, car il est je trouve normal et important que les API/ABI des bibliotheques soient stable entre deux releases mineurs et qu'en cas de majeur on puisse avoir une installation en parallele. Mais bon, tous les toolkits n'ont pas compris ca…
[^] # Re: C'est plus facile de travailler salement…
Posté par cedric . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Peut etre parce que Mir, c'est Ubuntu only (Va falloir compte le nombre de contribution externe non paye par Ubuntu) alors que Systemd a reussi a avoir le soutien de plusieurs distro et de beaucoup de developpeurs… Apres que tu sois grincheux et que tu n'aimes pas systemd ne va pas en faire une mauvaise solution technique, contrairement a Mir qui est juste une enorme betise (Protocol pas stable, pas de reflexion sur les inputs, la securite et un paquet d'optimisation necessaire pour baisser la conso).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Je repondais a ca:
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 5.
Euh,tu as loupe un gros détails, wayland est base sur de la mise a jour partiel de buffer pour toutes les frames. Plutôt bien adapté pour les codecs vidéo…
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 5.
J'ai juste dis performance. Et en ADSL avec NX (donc en echange de buffer compresse moins efficace que ce que peux faire Wayland), j'ai des performances meilleurs qu'en utilisant X avec des toolkits faisant du Xrender. Et aujourd'hui, la plus part des toolkits ont abandonnees de fait Xrender. Je ne connais pas de cas ou j'ai eu une meilleur utilisation avec Xrender. Bon apres, ca c'est peut etre ameliorer depuis qu'on a tue notre backend, il y a 2 ans, mais les performances ont toujours ete abyssal, en local et en distant.
NX fait de la compression de buffer tres efficacement qd tu exportes de l'export display et ca marche tres bien pour des terminaux qui n'utilisent pas Xrender. Donc si tu peux utiliser NX, tu pourras utiliser Wayland pour le meme usage.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 3.
Ah ah ah ! Oui :-)
Sauf que dans le cas du traitement de texte, tu vas vouloir avoir un controle tres fin du rendu, et il est peu probable que tu t'appuie sur le serveur graphique. Si tu veux avoir un resultat a peu pres proche de la sortie imprimante et du resultat sur Windows/MacOs, tu veux avoir le meme moteur de rendu… Donc je parie que tu ne passes pas aujourd'hui par XRender.
Sans compter que en terme de performance, c'est du texte que tu veux lire, donc tu n'es pas a vouloir le faire defiler a grande vitesse. Ca implique que au final, tu as des images tres statique avec de petit motion vector. Donc le rendu avec des sous-surfaces qui sont deplace donnera de bonne performance et laissera les choses tres utilisable. Ce sera probablement le cas pour les tableurs et les logiciels de messagerie aussi.
Il n'y a que les terminaux qui on un besoin de performance et de debit reseau reellement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Mouais, a part pour le cas tres particulier du urxvt qui tourne dans X, je vois pas trop qu'elle application a distance aura un interet a faire ce genre d'usage. J'en reviens a me demander pourquoi pas juste ssh ? Qu'est-ce que tu gagnes a mettre cette complexite dans Wayland.
Bon, apres d'un point de vue theorique, c'est pas forcement si impossible a pousser dans Wayland. Il suffit d'avoir un nouveau type de surface qui serait un buffer juste de texte et que les toolkits soient capable de l'utiliser pour decoreller le texte du reste. Mais bon, je reste tres dubitatif sur l'utilisation de cette technique pour ce requirement.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par cedric . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 9.
Vu les performances de XRender, je doutes qu'il y ait encore beaucoup de toolkit qui l'utilisent… A part xterm et probablement urxvt, il ne doit meme pas y avoir beaucoup de terminaux qui l'utilisent encore directement.
Vu l'echec de l'API de dessin de Wayland, c'est une bonne chose que de ne pas mettre un truc inutile dedans et de completement le decoreller en se reposant entre autre chose sur OpenGL/EGL.
Est-ce qu'il y a un seul toolkit qui utilise juste xcb ? La reponse est non pour une seule raison, il n'y a pas de support de XCB pour OpenGL de disponible avec la majorite des drivers (En fait, je ne sais meme pas si il y en a un qui le propose). Sur le papier xcb, c'est bien, mais au final, tu dois de toute facon avoir xlib, donc les toolkits se tappent une double stack qui n'apporte pas suffisament pour justifier l'effort.
J'avoue que j'ai du mal a comprendre cet objectif, si je veux juste du texte a distance, j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
[^] # Re: Supaire
Posté par cedric . En réponse au journal Faut-il arrêter l'Euro ?. Évalué à 3.
Ca ne marche que lorsque l'inflation est suivi par une croissance economique pour permettre l'augmentation des salaires. Si cela n'est pas le cas, ca ruine tout le monde, jeune et vieux. Les seuls qui s'en sortent sont ceux qui sont les plus riche pour qui la perte aura moins d'impact sur leur niveau de vie que sur les autres classes.
Et il n'y aura pas de croissance economique au niveau mondial pour les 20 ans a venir. C'est juste quelque chose d'idiot que de l'attendre et d'avoir un systeme calibre pour une tel situation. Il vaut mieux planifier la decroissance et le chomage de masse si on veut etre realiste.
Pour demontrer la decroissance a venir, c'est assez simple. La croissance economique passe est lie tres majoritairement a l'augmentation de notre consomation d'energie, pas au progres. Cela veut dire que si notre consomation d'energie stagne… c'est la crise ! D'ailleur on est globalement sur un palie depuis 2005. Et si elle commence a diminuer, et bien le progres ne pourra pas compenser les pertes, nous nous retrouverons donc en decroissance. La production mondiale de petrole devant commencer a descendre a partir de 2018/2020, je vous laisse en tirer les conclusions qui s'imposent.
Ah, et aussi, l'argent ne payant que les hommes, l'optimisation automatique d'un tel systeme veut qu'on supprime au maximum les hommes de tous les process. C'est a dire IA et robotique vont continuer a remplacer massivement les emplois. Il est temps d'abandonner le reve mythique du plein emploi et de revoir en profondeur notre systeme economique.
[^] # Re: Supaire
Posté par cedric . En réponse au journal Faut-il arrêter l'Euro ?. Évalué à 3.
L'inflation sans croissance, c'est un peu la strategie de l'echec ou celle de cacher la misere sous les tapis. L'inflation n'augmente pas le pouvoir d'achat reel des individus. Elle fait certe disparaitre les dettes passees, mais aussi les gains passes. Une joli strategie de cigale pour ruiner les fourmies !
A terme, l'inflation sans croissance, c'est juste un bain de sang. République de Weimar en est un bon exemple de resultat.
Ce qui est fondamental, c'est surtout de calibrer notre systeme pour une baisse de la croissance permanente dans les 20 prochaines annees, l'augmentation du nombre de retraites et du nombre de chomeurs. Sans un systeme resilient a ces parametres, ce sera la guerre civile. Et quand je dis resilient, je ne parle pas de dette ou de securite social, je parle d'un systeme dans lequel les gens acceptent de vivre sans aller en guerre ! Parce que aujourd'hui, c'est fondamentalement ca qui nous pend au nez.
D'un point de vue historique, on voit que les problemes serieux ont commence a pointer leur nez au debut des annees 70. Peut etre que le ralentissement de la croissance des approvisionnements en petrole et gaz pas chere a eu un impact. Peut etre que l'informatisation et la robotisation a reduit la necessite d'employer des grandes quantites de travailleurs pour boulonner et visser des voitures. Peut etre que notre comprehension en tant que civilisation de ce qu'a ete notre progres ces derniers siecles est completement fausse par le message des theories economiques d'un temps ou l'espece humaine etait dix fois moins nombreux et ou les apport externe pouvait etre considere comme infini.
Notre premier probleme, c'est d'avoir des theories economique qui prendre en compte les limites du monde dans lequel on vit ! Si on continue de suivre les theses qui ont deux siecles et pensent que notre pouvoir d'achat est uniquement lie a l'effort humain fournit (L'argent ne sert aujourd'hui que a payer des etres humain), on pourra imprimer tous les billets qu'on veut, le systeme s'ecroulera au final.