C'est apperement l'industrie mondiale qui fait le plus de marge, de l'ordre de 30%. Quand on sait les investissements des etats dans la recherche medicale et que c'est aussi eux qui dans un certain nombre de pays payent l'addition, il y a peut etre de petite chose a ajuster.
Je ne suis pas certain que comparer le design d'une orange et d'une pomme soit tres pertinent pour ce genre de sujet. Entre autre chose, OpenBSD n'est pas trop repute pour l'acceleration materielle de sa stack graphique… D'ailleur ca date de Fevrier le support pour les driver INTEL et AMD en KMS: http://undeadly.org/cgi?action=article&sid=20140223112426 …
Non, mais tu es serieux ? Tu penses vraiment que c'est redhat qui pousse systemd ? C'est une blague ???
L'auteur de Wayland est parti bosser chez Intel, car c'etait la qu'il pouvait bosser dans de bonne condition sur Wayland. C'est Intel qui pousse comme un malade sur Wayland aujourd'hui, et cela pour de veritable raison commercial. Apres il y a des gens qui bossent/bossaient chez Intel sur GNOME et qui ont fini par convaincre le reste de la communaute de GNOME d'avancer sur GNOME. Ca fait a peine 1 an que GNOME travail dessus. Ceux sont les derniers arrives sur le sujet !
Quand a pousser Wayland sur GNOME, c'est juste une evidence. Il est impossible par design de securiser dans un environnement X. A chaque fois que tu tappes un mot de passe sous X, tu as perdu. A chaque fois, sans exception ! Et comme le projet GNOME veut pouvoir enfin faire un eco systeme qui ne depend pas des distributions pour le packaging d'application, ils ont besoin d'une stack sure pour executer du code. Ils n'ont donc plus le choix, si ils veulent faire un truc qui ne transformera pas Linux en Windows Me.
Et pas la peine qu'on discute de Mir, c'est juste une tentative de Canonical de controler sa stack et c'est fait par des gens qui n'ont aucune idee de ce que doit faire un composite manager.
Tu pars du principe que c'est facile de trouver un developpeur :-) Ces tarifs sont atteinds dans la Silicon Valley pour une raison simple. Il y a un vrai manque de developpeur dans certain domaine. Forcement quand tu es le centre de la creation de logiciel au monde, il te faut du monde ! Comme tout le monde ne veut pas bouger la bas et qu'ils ne maitrisent pas encore si bien que ca le teletravail (un comble). Il y a forcement une tres forte competition entre les societes pour recruter. Hors ce qui est rare, est chere… C'est probablement une bulle speculative, mais tant que la Silicon Valley aura besoin de physiquement autant de developpeur sur son territoire, le tarif montera.
En France, on a bien compris que ca servait a rien un developpeur. Suffit de prendre n'importe qui sorti d'ecole et il te codera ce que ton departement marketing aura pense. Pas la peine d'avoir la moindre expertise technique, ca ne sert a rien dans ce domaine. C'est juste des executants et au pire on ira en Inde pour sous traiter (Pour le cout, on maitrise le teletravail…) et en plus, ils seront moins ch…, car ils n'auront pas envie de valoriser leurs idees. En tout cas, c'est la logique que j'ai vu le plus souvent applique dans les grosses societes Francaise (Resultat les meilleurs developpeurs partent rapidement soit a l'etranger soit sur des postes non technique).
Je me pose encore la question de la raison de cette strategie tres idiote. Je pense que c'est un effet de nos grandes ecoles et de problemes d'ego genere par celle-ci. Si tu n'as pas fait la meme ecole que moi, c'est que tu es un idiot et donc je sais tout mieux que toi… Ce qui cree aussi des problemes de management assez important vu qu'on a des gens qui deviennent manager sans formation valable en se croyant meilleur que tout le monde et qui n'ecouteront personne.
Il n'y a pas de WM porte sur Wayland. Weston, l'implementation de reference de Wayland, est tres modulaire, mais la politique de placement de fenetre est interne au Composite Manager. C'est le cas pour toutes les implementations que je connais de compositeur qui support Wayland. Et je ne connais pas de WM seul ayant ete porte sous Weston.
Pour l'instant tous les bureaux qui sont entrain d'implementer Wayland sont parti sur des approches techniques apriori legerement differente autant que je sache.
kwin/kde: au dessus de Weston (en tant que compositeur system), mais en forcant les applications a ne pas rendre leur bordure de fenetre.
mutter/gnome: implementation sans compositeur system de leur propre compositeur et en laissant au toolkit la gestion des bordures de fenetre.
enlightenment: implementation decorele entre le backend de rendu et le support du protocol Wayland, les bordures de fenetres sont laisse aux toolkits.
Il y aussi une autre difference probable, Enlightenment fonctionne principalement a l'aide de module et non d'executable externe, ce qui change aussi certaine chose au final. Dans l'ensemble, je ne pense pas que honnetement on puisse dire qu'il y a une meilleur piste qu'une autre a suivre aujourd'hui. Il va forcement y avoir une periode de recherche qui va donner de nombreuses variation et difference, puis les choses se stabiliseront. Clairement Wayland sur le desktop, ca va prendre un peu de temps…
En meme temps, X n'est pas mort et continue d'evoluer aussi (meme si il y a des problemes qu'il ne pourra jamais resoudre). Et puis si vous voulez voir votre desktop plus vite vers Wayland, suffit de contribuer ;-)
Une solution alternative explore par Lucas De Marchi ingenieur chez Intel ( http://www.politreco.com/ ). En gros, au lieu d'avoir une structure simple derriere la table de hash, on fait appel a une structure un peu plus complexe qui permet de diminuer l'impact d'une collision. En passant a du O(log n) dans le pire cas.
Avec des donnees reelles, on se rend compte que dans ce cas, on peut utiliser une fonction de hash de type CRC32 qui va generer des collisions a foison, et obtenir de meilleur performance sur des cas reelles sans risque de faiblesse de la fonction de hash. De plus, CRC32 pouvant etre accelere en hardware, on se retrouve avec de plus un meilleur temps constant que les fonctions plus complexe.
Qt et la glib ont ete impacte par ce bug des tables de hash, il y a un peu plus d'un an. Leur solution a ete de rajouter un seed random pris au demarrage de l'application. Les EFL utilisaient deja une structure complexe (combine de rbtree et hash) et n'ont pas impacte (Ce qui a lance la reflection sur une fonction de hashage plus simple et rapide).
Mouah ah ah ah ! Proxy, forward de port, transfert de fichiers, shell distant, … C'est un couteau suisse ton outil ! Reecrire un client/serveur SSH, c'est du gros boulot tout de meme ! La difference, c'est que tu as l'habitude de OpenSSH, alors que systemd est nouveau pour toi.
Elles ne sont pas si rare,les terres rares. Leur problème,c'est qu'elles sont très souvent mélangées a du thorium… produit radioactif qui n'est pour l'instant pas vraiment utilisable pour produire de l'énergie et devient donc un déchet radioactif de l'activité des mines. Les chinois ont des lois moins sévères sur le stockage de ces produits, ceux qui leur permet leur exploitation, mais ils ont aussi compris l'intérêt potentiel du thorium et ceux sont aujourd'hui les plus gros investisseurs dans la recherche pour transformer ces déchets en quelque chose de plus utile.
Prend le problème a l'envers combien de société ont des environnement techniques et des projets intéressant qui ferait qu'un développeur voudrait travailler pour elle en France et y avoir une carrière technique intéressante ?
Exactement, dans le cas d'un lecteur vidéo, tu suivra le framerate de la vidéo et tu n'as probablement pas d'animation kikoolol durant la lecture. Il y a aussi probablement pas beaucoup d'objets affiché et il n'est plus nécessaire de garder en mémoire les menus et autres éléments graphique qui ne seront très probablement pas utilisé avant la fin de la vidéo.
Pour le visualisateur d'image, c'est probablement encore mieux,vu que tu ne vas pas changer d'image a chaque frame. Il faut juste pouvoir près chargé l'image a venir… le seul cas,ou je vois un problème potentiel,c'est si tu veux faire l'effet mal de mer avec une animation a 60fps. La,il faudra forcer la main et ne pas laisser le toolkit descendre le framerate.
Mais tu pensais probablement a un problème en prenant ces deux exemples, non ?
Dans la majorite des telephones du marche (surtout les moins cheres), le CPU Baseband et le CPU Applicatif sous dans la meme puce et on acces a la meme memoire. Il n'y a pas de controle du CPU Applicatif sur le mapping memoire du CPU Baseband, c'est du cooperatif. Donc de base parler ici d'une faille de securite pour un truc qui est probablement dedie a un systeme de mise a jour de firmware, c'est juste secondaire comme probleme.
Le seul interet que je vois a cette news, c'est que le grand public aura peut etre une chance d'avoir un appercu des problemes de securite des telephones. C'est pas tout, mais les revelations de Snowden n'ont pas change grand chose dans le domaine. On a toujours des gens qui pensent qu'on peut avoir une solution securise en mettant en place un firmware proprietaire… Voir meme un OS proprietaire…
Ici, par contre, je soupçonne que le développement du bousin n'ait seulement pour but le bien de l'humanité en toute abnégation. Alors qu'est-ce qui motive les auteurs ("a bunch of geeks in Buenos Aires", d'après le site)?
Le fait d'avoir une infrastructure decentralise et user friendly pour tout le monde. Une alternative a Google et Youtube… Un moyen de faire c…. les ayants droits et leur loi de plus en plus anti democratique en mettant en place un outil que tout le monde peut utiliser.
Trouver des raisons a developper un tel logiciel, c'est pas vraiment ce qui manque. Ce qui manque en general, c'est le temps pour le developper…
Et pourquoi ne pas faire faire cela directement par le compositeur en rajoutant un protocol ask-pass ? Cela permettrait de clairement identifier qui fait la demande en donnant un bon controle au gestionnaire de fenetre pour renforce une police de securite. Etant donnee que tous les compositeurs viennent avec un toolkit graphique, avoir une gestion de la demande du mot de passe directement dans le compositeur n'est clairement pas un probleme technique.
Une application qui n'a plus le focus, n'a plus d'interaction avec l'utilisateur. Ce qui limite de maniere tres importante le domaine de ce qui va s'y passer. Il devient donc logique de dropper une bonne partie des donnees en cache (qui servent principalement pour reagir lors d'une interaction utilisateur). Et il est meme probable que de leger frame drop sont acceptable lors des animations imprevisibles qu'une application peut generer (Affichage de log dans une liste, ou resultat de traffic reseau).
Du cote des experiences mene dans ce domaine, Enlightenment change dynamiquement la priorite des taches pour avoir toujours une plus grande priorite a la tache qui a le focus. Cela est le cas depuis deja 10 ans ou presque et aucun utilisateur n'y a trouve a redire. Donc accepter de perdre un peu de performance au benefice de la charge memoire est a mon sens completement acceptable dans ce scenario.
Bon, on ne va pas non plus etre super aggressif dans le scenario de la perte de focus et on gardera donc plus de donnees pretes a l'utilisation. Mais dans le scenario ou une application n'est plus affiche du tout a l'ecran, la on va devenir tres aggressif sur notre usage memoire. Si c'est une application OpenGL, on va dropper le context. Si c'est une simple application en rendu software, on va juste dropper tous les buffers et la majeure partie des ressources graphiques. En supplement on travail aujourd'hui a compresser/defragmenter a la vole les structures de nos objets.
Avec le compositing, une appli ne sait jamais si elle est visible ou pas, et c'est très bien comme ça sinon ça pose d'autres problèmes.
Pas sous X. Sous X lorsqu'une application est iconifie, sa fenetre n'est plus mappe et il est donc possible pour le toolkit de le detecter. Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence. Savoir comment une fenetre est utilise, est tres pratique pour pas mal de cas. Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ? Est-ce que ca ne vaudrait pas le cout de ne negocier qu'une mini version avec une mise a jour plus lente ? Il y a plein d'effet exigeant pour le CPU et le GPU sur un desktop qui s'y ils avaient a manipuler des fenetres plus adapte a la sortie sur l'ecran, consommerait nettement moins de ressource (et donc pourrer tourner sur des machines plus limite).
Pourquoi une liste serait dans un plan différent, ça apporte quoi? Ne pas avoir à re-rendre la liste?
Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
Je sais pas à quel vitesse on peut allouer un plan, mais ça devrait pas être trop lent.
En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire…
Cite moi des cas pratiques où la négociation apporte des avantages et on verra si ça a vraiment un sens (je suis vraiment sceptique).
L'exemple le plus simple, c'est une application qui n'a plus le focus et donc n'a plus d'activiter. En forcant l'utilisation permanente de buffer, tu augmentes la consomation de memoire de tes applications en tache de fond. Certe on pourrait juste eviter la negociation et se dire que des qu'une application est en tache de fond, alors on peut juste droper les buffers et faire un rendu flat.
Autre exemple, ou on aurait un benefice, tu as une application avec deux listes qui necessites donc normalement 2+3*2 plans. Or ton systeme ne les fournit pas. Hors une seule des deux listes est activement anime. Si tu as une negociation dynamique, l'application va utiliser des buffers pour une seule des listes et droper les buffers asap pour l'autre liste. Par contre, sans negociation, le compositeur doit determiner quel sont les buffers qu'il vaut mieux mettre dans un plan et ceux qu'il vaut mieux "compositer". Or il va avoir du mal a le faire en avance, car il ne sait pas quel buffer va etre bouge lors de la prochaine frame. Il se retrouve a prendre une decision au hazard et peut etre faire un compositing de trop. Alternativement, le toolkit peut en permanence minimiser le nombre de plan qu'il utilise. Mais auquel cas, meme lorsque tu as un hardware capable de gerer le nombre maximum, tu te retrouves a avoir un risque de frame drop lors du debut de l'animation de la seconde liste.
Pour AMD, ca fait des annees que j'ai arrete de m'interresser a leur plateforme du fait des problemes de stabilites de leur driver proprio qui ne peut servir globalement qu'a faire des jeux… et encore ! Nous recevons la majorite de nos rapports de bug driver en provenance de leur plateforme, donc je ne suis pas pres de changer d'avis tout de suite (Meme si apparement le driver radeon semble avoir moins de probleme que le driver proprio).
Pour ce qui est de Intel, ce n'est pas une question d'etre sur le meme die, mais bien d'utiliser le meme format interne que le GPU. Celui-ci est souvent tile (en gros un espece de pavage avec un ordre plus ou moins bizarre en fonction du GPU) et necessite donc quelques manipulations de pixels d'un cote ou de l'autre. Si ce n'est pas fait, la manipulation des dites ressources devient plus lente et consomme donc plus d'energie.
Du coup, je vois pas ce que ça t'apporte en terme de complexité si ce n'est de rendre l'exécution des applications plus complexe (imagine les cas où 3 planes seront dispo, ça marche et quand y'en a 4 ou 6, ça marche plus, va debugger ça!).
La question du test n'est pas un vrai probleme, car la logique de gestion des plans cote toolkit est quelque chose de similaire quelque soit le backend (software ou GL). Il est donc envisageable de simuler le fonctionnement sans dependre du protocol Wayland (Et rendre le debuggage tout a fait jouable). Pour ce qui de l'avantage, plus tu demandes de travail au serveur alors que ce n'est pas necessaire. Tu augmentes la charge de travail et donc la consomation d'energie. Probablement aussi reduit les performances du systeme. Mais il est vrai qu'il faudra faire le test pour en etre certain.
Pour les subsurfaces qui supportent mal le clipping, faut étendre le protocole.
Alors sur mon PC (Samsung Series 9 13" de 2012) avec Enlightenment et Terminology, j'obtiens les chiffres suivant :
en idle :
rendu CPU : 9.99 W
rendu GPU : 10.9 W
en faisant bouger une fenetre :
rendu CPU : 11.1 W
rendu GPU : 11.5 W
En activant le canal alpha sur la fenetre de terminology :
en idle :
rendu CPU : 10.7 W
rendu GPU : 10.9 W
en faisant bouger une fenetre :
rendu CPU : 11.7 W
rendu GPU : 11.6 W
Ca correspond a ce que j'attendais et c'est completement logique. Le cas de la figure transparente qui bouge consomme plus avec le CPU que le GPU, car on a passe la limite entre le surcout d'utiliser le GPU et celui du CPU.
J'ai fais tous les tests avec une version git des efl et en utilisant powertop pour mesurer la consomation (Wifi et Ethernet desactive, luminosite ecran au minimum). Par contre, j'ai une regression quelque part dans mon systeme, car je descendais a 8 ou 7W, il y a 3 mois. Mais je ne pense pas que ca ait un impact sur les resultats.
Et comment tu fais ton protocole de réservation de plane? Si tu veux utiliser plusieurs planes dans Wayland, tu utilises les subsurfaces.
Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
Un exemple de cas qui marcherait pas si on faisait comme tu le dis, les screenshots.
Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
Mais bon, tu peux tjs rendre la différence sur ton CPU et demander à la carte de faire le blit sur le buffer actuel. Pas besoin de faire un accès direct ni de re-rendre toute l'image.
Ce qui revient donc a une copie :-)
J'étais sous KDE.
Hum, je ne connais pas trop kde, mais je ne savais pas qu'ils avaient un rendu CPU. Intéressant. Je vais voir si je me motive pour faire un benchmark croisé ce weekend, ou si je teste juste avec enlightenment. Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
C'est pas au toolkit de gérer ça. Y'a que le compositeur qui peut les utiliser ou, au moins, les attribuer à des clients graphiques. Ces clients n'ont jamais à gérer l'affichage dans Wayland, ils ne font que rendre des buffers.
Ah, mais si, c'est au toolkit de gérer ça ! Il faut a terme que le protocole indique aux applications le nombre de layer disponible pour que celui ci prenne la meilleur décision possible concernant le nombre de buffer a utiliser. Ensuite le serveur wayland devra juste programmer kms pour placer les dis buffer dans les bons plans.
Il ne faut pas oublier que certaines machine peuvent gérer de l'ordre de la dizaine de plans simultanées (exemples la raspberry pi ). Il serait dommage de ne pas en tirer partie (cela demande certe beaucoup d'infrastructure dans les toolkit, mais pour gagner niveau consommation comme rien d'autres !).
# En parlant d'industrie pharmaceutique
Posté par cedric . En réponse au journal Abolir les brevets ?. Évalué à 4.
C'est apperement l'industrie mondiale qui fait le plus de marge, de l'ordre de 30%. Quand on sait les investissements des etats dans la recherche medicale et que c'est aussi eux qui dans un certain nombre de pays payent l'addition, il y a peut etre de petite chose a ajuster.
[^] # Re: troll velu avec systemd
Posté par cedric . En réponse au journal Sur systemd, btrfs & co. Évalué à 3.
Je ne suis pas certain que comparer le design d'une orange et d'une pomme soit tres pertinent pour ce genre de sujet. Entre autre chose, OpenBSD n'est pas trop repute pour l'acceleration materielle de sa stack graphique… D'ailleur ca date de Fevrier le support pour les driver INTEL et AMD en KMS: http://undeadly.org/cgi?action=article&sid=20140223112426 …
[^] # Re: troll velu avec systemd
Posté par cedric . En réponse au journal Sur systemd, btrfs & co. Évalué à 8.
Non, mais tu es serieux ? Tu penses vraiment que c'est redhat qui pousse systemd ? C'est une blague ???
L'auteur de Wayland est parti bosser chez Intel, car c'etait la qu'il pouvait bosser dans de bonne condition sur Wayland. C'est Intel qui pousse comme un malade sur Wayland aujourd'hui, et cela pour de veritable raison commercial. Apres il y a des gens qui bossent/bossaient chez Intel sur GNOME et qui ont fini par convaincre le reste de la communaute de GNOME d'avancer sur GNOME. Ca fait a peine 1 an que GNOME travail dessus. Ceux sont les derniers arrives sur le sujet !
Quand a pousser Wayland sur GNOME, c'est juste une evidence. Il est impossible par design de securiser dans un environnement X. A chaque fois que tu tappes un mot de passe sous X, tu as perdu. A chaque fois, sans exception ! Et comme le projet GNOME veut pouvoir enfin faire un eco systeme qui ne depend pas des distributions pour le packaging d'application, ils ont besoin d'une stack sure pour executer du code. Ils n'ont donc plus le choix, si ils veulent faire un truc qui ne transformera pas Linux en Windows Me.
Et pas la peine qu'on discute de Mir, c'est juste une tentative de Canonical de controler sa stack et c'est fait par des gens qui n'ont aucune idee de ce que doit faire un composite manager.
[^] # Re: Attendons encore un peut...
Posté par cedric . En réponse au journal FirefoxOS: ou pas.... Évalué à 4.
Jolla: http://jolla.com/ ?
[^] # Re: ingénieur peu considéré en France
Posté par cedric . En réponse au journal Téléphoner à ma mère: gratuité, simplicité, liberté ou vie privée?. Évalué à 10.
Tu pars du principe que c'est facile de trouver un developpeur :-) Ces tarifs sont atteinds dans la Silicon Valley pour une raison simple. Il y a un vrai manque de developpeur dans certain domaine. Forcement quand tu es le centre de la creation de logiciel au monde, il te faut du monde ! Comme tout le monde ne veut pas bouger la bas et qu'ils ne maitrisent pas encore si bien que ca le teletravail (un comble). Il y a forcement une tres forte competition entre les societes pour recruter. Hors ce qui est rare, est chere… C'est probablement une bulle speculative, mais tant que la Silicon Valley aura besoin de physiquement autant de developpeur sur son territoire, le tarif montera.
En France, on a bien compris que ca servait a rien un developpeur. Suffit de prendre n'importe qui sorti d'ecole et il te codera ce que ton departement marketing aura pense. Pas la peine d'avoir la moindre expertise technique, ca ne sert a rien dans ce domaine. C'est juste des executants et au pire on ira en Inde pour sous traiter (Pour le cout, on maitrise le teletravail…) et en plus, ils seront moins ch…, car ils n'auront pas envie de valoriser leurs idees. En tout cas, c'est la logique que j'ai vu le plus souvent applique dans les grosses societes Francaise (Resultat les meilleurs developpeurs partent rapidement soit a l'etranger soit sur des postes non technique).
Je me pose encore la question de la raison de cette strategie tres idiote. Je pense que c'est un effet de nos grandes ecoles et de problemes d'ego genere par celle-ci. Si tu n'as pas fait la meme ecole que moi, c'est que tu es un idiot et donc je sais tout mieux que toi… Ce qui cree aussi des problemes de management assez important vu qu'on a des gens qui deviennent manager sans formation valable en se croyant meilleur que tout le monde et qui n'ecouteront personne.
[^] # Re: Manque de comparaison
Posté par cedric . En réponse au journal Cairo Dock pour Wayland. Évalué à 3.
Elle a un impact direct sur la consomation memoire et les performances de rendu, donc probablement sur la batterie.
[^] # Re: Manque de comparaison
Posté par cedric . En réponse au journal Cairo Dock pour Wayland. Évalué à 2.
Il n'y a pas de WM porte sur Wayland. Weston, l'implementation de reference de Wayland, est tres modulaire, mais la politique de placement de fenetre est interne au Composite Manager. C'est le cas pour toutes les implementations que je connais de compositeur qui support Wayland. Et je ne connais pas de WM seul ayant ete porte sous Weston.
[^] # Re: Manque de comparaison
Posté par cedric . En réponse au journal Cairo Dock pour Wayland. Évalué à 5.
Pour l'instant tous les bureaux qui sont entrain d'implementer Wayland sont parti sur des approches techniques apriori legerement differente autant que je sache.
Il y aussi une autre difference probable, Enlightenment fonctionne principalement a l'aide de module et non d'executable externe, ce qui change aussi certaine chose au final. Dans l'ensemble, je ne pense pas que honnetement on puisse dire qu'il y a une meilleur piste qu'une autre a suivre aujourd'hui. Il va forcement y avoir une periode de recherche qui va donner de nombreuses variation et difference, puis les choses se stabiliseront. Clairement Wayland sur le desktop, ca va prendre un peu de temps…
En meme temps, X n'est pas mort et continue d'evoluer aussi (meme si il y a des problemes qu'il ne pourra jamais resoudre). Et puis si vous voulez voir votre desktop plus vite vers Wayland, suffit de contribuer ;-)
# Solution alternative
Posté par cedric . En réponse au journal OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à -1.
Une solution alternative explore par Lucas De Marchi ingenieur chez Intel ( http://www.politreco.com/ ). En gros, au lieu d'avoir une structure simple derriere la table de hash, on fait appel a une structure un peu plus complexe qui permet de diminuer l'impact d'une collision. En passant a du O(log n) dans le pire cas.
Avec des donnees reelles, on se rend compte que dans ce cas, on peut utiliser une fonction de hash de type CRC32 qui va generer des collisions a foison, et obtenir de meilleur performance sur des cas reelles sans risque de faiblesse de la fonction de hash. De plus, CRC32 pouvant etre accelere en hardware, on se retrouve avec de plus un meilleur temps constant que les fonctions plus complexe.
Qt et la glib ont ete impacte par ce bug des tables de hash, il y a un peu plus d'un an. Leur solution a ete de rajouter un seed random pris au demarrage de l'application. Les EFL utilisaient deja une structure complexe (combine de rbtree et hash) et n'ont pas impacte (Ce qui a lance la reflection sur une fonction de hashage plus simple et rapide).
[^] # Re: L'avis d'un mainteneur.
Posté par cedric . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 8.
Mouah ah ah ah ! Proxy, forward de port, transfert de fichiers, shell distant, … C'est un couteau suisse ton outil ! Reecrire un client/serveur SSH, c'est du gros boulot tout de meme ! La difference, c'est que tu as l'habitude de OpenSSH, alors que systemd est nouveau pour toi.
[^] # Re: Vortex86
Posté par cedric . En réponse au journal Minnowboard : 2ème essai. Évalué à 2.
Elles ne sont pas si rare,les terres rares. Leur problème,c'est qu'elles sont très souvent mélangées a du thorium… produit radioactif qui n'est pour l'instant pas vraiment utilisable pour produire de l'énergie et devient donc un déchet radioactif de l'activité des mines. Les chinois ont des lois moins sévères sur le stockage de ces produits, ceux qui leur permet leur exploitation, mais ils ont aussi compris l'intérêt potentiel du thorium et ceux sont aujourd'hui les plus gros investisseurs dans la recherche pour transformer ces déchets en quelque chose de plus utile.
[^] # Re: Les géants de l'informatique
Posté par cedric . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 10.
Prend le problème a l'envers combien de société ont des environnement techniques et des projets intéressant qui ferait qu'un développeur voudrait travailler pour elle en France et y avoir une carrière technique intéressante ?
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Exactement, dans le cas d'un lecteur vidéo, tu suivra le framerate de la vidéo et tu n'as probablement pas d'animation kikoolol durant la lecture. Il y a aussi probablement pas beaucoup d'objets affiché et il n'est plus nécessaire de garder en mémoire les menus et autres éléments graphique qui ne seront très probablement pas utilisé avant la fin de la vidéo.
Pour le visualisateur d'image, c'est probablement encore mieux,vu que tu ne vas pas changer d'image a chaque frame. Il faut juste pouvoir près chargé l'image a venir… le seul cas,ou je vois un problème potentiel,c'est si tu veux faire l'effet mal de mer avec une animation a 60fps. La,il faudra forcer la main et ne pas laisser le toolkit descendre le framerate.
Mais tu pensais probablement a un problème en prenant ces deux exemples, non ?
[^] # Re: Firefox OS
Posté par cedric . En réponse au journal Porte dérobée sur Samsung Galaxy - Projet Replicant. Évalué à 10.
Dans la majorite des telephones du marche (surtout les moins cheres), le CPU Baseband et le CPU Applicatif sous dans la meme puce et on acces a la meme memoire. Il n'y a pas de controle du CPU Applicatif sur le mapping memoire du CPU Baseband, c'est du cooperatif. Donc de base parler ici d'une faille de securite pour un truc qui est probablement dedie a un systeme de mise a jour de firmware, c'est juste secondaire comme probleme.
Le seul interet que je vois a cette news, c'est que le grand public aura peut etre une chance d'avoir un appercu des problemes de securite des telephones. C'est pas tout, mais les revelations de Snowden n'ont pas change grand chose dans le domaine. On a toujours des gens qui pensent qu'on peut avoir une solution securise en mettant en place un firmware proprietaire… Voir meme un OS proprietaire…
[^] # Re: Super
Posté par cedric . En réponse au journal Popcorn Time, la vidéo à la demande (presque) parfaite. Évalué à 9.
Le fait d'avoir une infrastructure decentralise et user friendly pour tout le monde. Une alternative a Google et Youtube… Un moyen de faire c…. les ayants droits et leur loi de plus en plus anti democratique en mettant en place un outil que tout le monde peut utiliser.
Trouver des raisons a developper un tel logiciel, c'est pas vraiment ce qui manque. Ce qui manque en general, c'est le temps pour le developper…
[^] # Re: Boite de dialogue pour les mots de passe
Posté par cedric . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 7.
Et pourquoi ne pas faire faire cela directement par le compositeur en rajoutant un protocol ask-pass ? Cela permettrait de clairement identifier qui fait la demande en donnant un bon controle au gestionnaire de fenetre pour renforce une police de securite. Etant donnee que tous les compositeurs viennent avec un toolkit graphique, avoir une gestion de la demande du mot de passe directement dans le compositeur n'est clairement pas un probleme technique.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Une application qui n'a plus le focus, n'a plus d'interaction avec l'utilisateur. Ce qui limite de maniere tres importante le domaine de ce qui va s'y passer. Il devient donc logique de dropper une bonne partie des donnees en cache (qui servent principalement pour reagir lors d'une interaction utilisateur). Et il est meme probable que de leger frame drop sont acceptable lors des animations imprevisibles qu'une application peut generer (Affichage de log dans une liste, ou resultat de traffic reseau).
Du cote des experiences mene dans ce domaine, Enlightenment change dynamiquement la priorite des taches pour avoir toujours une plus grande priorite a la tache qui a le focus. Cela est le cas depuis deja 10 ans ou presque et aucun utilisateur n'y a trouve a redire. Donc accepter de perdre un peu de performance au benefice de la charge memoire est a mon sens completement acceptable dans ce scenario.
Bon, on ne va pas non plus etre super aggressif dans le scenario de la perte de focus et on gardera donc plus de donnees pretes a l'utilisation. Mais dans le scenario ou une application n'est plus affiche du tout a l'ecran, la on va devenir tres aggressif sur notre usage memoire. Si c'est une application OpenGL, on va dropper le context. Si c'est une simple application en rendu software, on va juste dropper tous les buffers et la majeure partie des ressources graphiques. En supplement on travail aujourd'hui a compresser/defragmenter a la vole les structures de nos objets.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Pas sous X. Sous X lorsqu'une application est iconifie, sa fenetre n'est plus mappe et il est donc possible pour le toolkit de le detecter. Et pour le focus, c'est pareil, on peut parfaitement le detecter et agir en consequence. Savoir comment une fenetre est utilise, est tres pratique pour pas mal de cas. Pense par exemple que tu as un pager qui affiche une miniature d'une fenetre ouverte sur un desktop virtuel que tu ne vois pas autrement, a quoi cela sert-il de rafraichir son contenu en haute resolution a 60fps ? Est-ce que ca ne vaudrait pas le cout de ne negocier qu'une mini version avec une mise a jour plus lente ? Il y a plein d'effet exigeant pour le CPU et le GPU sur un desktop qui s'y ils avaient a manipuler des fenetres plus adapte a la sortie sur l'ecran, consommerait nettement moins de ressource (et donc pourrer tourner sur des machines plus limite).
Tu decoupes la liste en 3 morceaux de chacun 2/3 de la taille de la liste a l'ecran. Tu remplis chaque morceau en avance, puis tu ne fais que deplacer les elements. Quand tu depasses les 1/3 de la liste dans une direction ou dans l'autre, tu ne redessines en asynchrone qu'un des trois buffers. Ca limite grandement les chances de frame drop et tu as une tres faible utilisation CPU et GPU, donc basse consomation et fonctionne sur une plus grande gamme de materiel.
En general, c'est tres lent et on est oblige (en tout cas sous X) de faire des caches pour ne pas en allouer trop souvent. Il ne faut pas obliger que entre deux images, on n'a que 16ms pour tout faire…
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
L'exemple le plus simple, c'est une application qui n'a plus le focus et donc n'a plus d'activiter. En forcant l'utilisation permanente de buffer, tu augmentes la consomation de memoire de tes applications en tache de fond. Certe on pourrait juste eviter la negociation et se dire que des qu'une application est en tache de fond, alors on peut juste droper les buffers et faire un rendu flat.
Autre exemple, ou on aurait un benefice, tu as une application avec deux listes qui necessites donc normalement 2+3*2 plans. Or ton systeme ne les fournit pas. Hors une seule des deux listes est activement anime. Si tu as une negociation dynamique, l'application va utiliser des buffers pour une seule des listes et droper les buffers asap pour l'autre liste. Par contre, sans negociation, le compositeur doit determiner quel sont les buffers qu'il vaut mieux mettre dans un plan et ceux qu'il vaut mieux "compositer". Or il va avoir du mal a le faire en avance, car il ne sait pas quel buffer va etre bouge lors de la prochaine frame. Il se retrouve a prendre une decision au hazard et peut etre faire un compositing de trop. Alternativement, le toolkit peut en permanence minimiser le nombre de plan qu'il utilise. Mais auquel cas, meme lorsque tu as un hardware capable de gerer le nombre maximum, tu te retrouves a avoir un risque de frame drop lors du debut de l'animation de la seconde liste.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Pour AMD, ca fait des annees que j'ai arrete de m'interresser a leur plateforme du fait des problemes de stabilites de leur driver proprio qui ne peut servir globalement qu'a faire des jeux… et encore ! Nous recevons la majorite de nos rapports de bug driver en provenance de leur plateforme, donc je ne suis pas pres de changer d'avis tout de suite (Meme si apparement le driver radeon semble avoir moins de probleme que le driver proprio).
Pour ce qui est de Intel, ce n'est pas une question d'etre sur le meme die, mais bien d'utiliser le meme format interne que le GPU. Celui-ci est souvent tile (en gros un espece de pavage avec un ordre plus ou moins bizarre en fonction du GPU) et necessite donc quelques manipulations de pixels d'un cote ou de l'autre. Si ce n'est pas fait, la manipulation des dites ressources devient plus lente et consomme donc plus d'energie.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
La question du test n'est pas un vrai probleme, car la logique de gestion des plans cote toolkit est quelque chose de similaire quelque soit le backend (software ou GL). Il est donc envisageable de simuler le fonctionnement sans dependre du protocol Wayland (Et rendre le debuggage tout a fait jouable). Pour ce qui de l'avantage, plus tu demandes de travail au serveur alors que ce n'est pas necessaire. Tu augmentes la charge de travail et donc la consomation d'energie. Probablement aussi reduit les performances du systeme. Mais il est vrai qu'il faudra faire le test pour en etre certain.
Oui.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
C'est un systeme Ivy-Bridge i7-3517U.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Alors sur mon PC (Samsung Series 9 13" de 2012) avec Enlightenment et Terminology, j'obtiens les chiffres suivant :
en idle :
en faisant bouger une fenetre :
En activant le canal alpha sur la fenetre de terminology :
en idle :
en faisant bouger une fenetre :
Ca correspond a ce que j'attendais et c'est completement logique. Le cas de la figure transparente qui bouge consomme plus avec le CPU que le GPU, car on a passe la limite entre le surcout d'utiliser le GPU et celui du CPU.
J'ai fais tous les tests avec une version git des efl et en utilisant powertop pour mesurer la consomation (Wifi et Ethernet desactive, luminosite ecran au minimum). Par contre, j'ai une regression quelque part dans mon systeme, car je descendais a 8 ou 7W, il y a 3 mois. Mais je ne pense pas que ca ait un impact sur les resultats.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 0.
Nop, il faut une "négociations", sinon tu te retrouve a devoir gérer plus d'information côté compositer que nécessaire ! De plus les sub surface ne gèrent pas le clipping de manière suffisante si je me souviens bien pour cette tâche. Il sera nécessaire d'étendre le protocole.
Je ne vois pas pourquoi. Tu as de toute façon accès a tous les buffer. Mais je n'ai pas regarder cette aspect plus que de manière théorique pour l'instant.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
Ce qui revient donc a une copie :-)
Hum, je ne connais pas trop kde, mais je ne savais pas qu'ils avaient un rendu CPU. Intéressant. Je vais voir si je me motive pour faire un benchmark croisé ce weekend, ou si je teste juste avec enlightenment. Pour gagner un peu de temps, tu peux me décrire comment activer le rendu CPU ?
Ah, mais si, c'est au toolkit de gérer ça ! Il faut a terme que le protocole indique aux applications le nombre de layer disponible pour que celui ci prenne la meilleur décision possible concernant le nombre de buffer a utiliser. Ensuite le serveur wayland devra juste programmer kms pour placer les dis buffer dans les bons plans.
Il ne faut pas oublier que certaines machine peuvent gérer de l'ordre de la dizaine de plans simultanées (exemples la raspberry pi ). Il serait dommage de ne pas en tirer partie (cela demande certe beaucoup d'infrastructure dans les toolkit, mais pour gagner niveau consommation comme rien d'autres !).