cedric a écrit 1074 commentaires

Ou peut etre qu'en trente an la technologie a evolue :-)

Le solaire thermique aujourd'hui ca permet de produire de l'energie H24 sans interruption. Il y a ma connaissance une centrale operationnelle en Italie et une en construction en Egypte.

J'aimerais quand meme nuancer le truc. Meego est techniquement une reinvention de la roue dans beaucoup de domaine. Ca a beau etre libre, des fois certaines grosses societes parce qu'elles ont beaucoup d'argent, veulent imposer leur solution.

Ainsi pour la distribution, partir d'un truc from scratch plutot que de solution existente comme OpenEmbedded ou debian, pose des gros soucis. Absence de beaucoup de paquet et il faut donc voir le projet Meego comme un projet de distribution complete. Rajoutons la difficulte de passer d'une version n a n+1. Des trucs de base gere par toutes les distributions, mais forcement ca demande du temps pour faire une distributions vraiment complete.

Ensuite vouloir faire son remplacant de X avec Wayland, c'est encore un projet tres ambitieux. Recoder des interfaces pour netbook, pour tv, pour telephone, ... La liste est tellement longue, qu'il est difficile d'imaginer que ce projet va donner des resultats vraiment concret et utilisable. Il suffit de lancer la version Meego pour netbook et de se rendre compte du chemin qu'il reste a parcourir...

Je vois assez mal comment un tel projet pourrait reussir a donner quelque chose surtout que meme en interne les efforts sont disparates. Des trucs sur QT dans un sens, d'autre sur mutter dans l'autre sens, ... Plus on observe techniquement le projet, plus il devient evident que Nokia devait aller chercher une solution ailleur. Meego aura surement une chance dans l'embarque facon Intel, mais probablement peu aupres du grand public...

Tout a fait d'accord, il n'y a pas que le code qui compte. L'organisation d'evenenement, de rencontre physique ou de maniere generale juste parler du projet, c'est deja aider et ca compte beaucoup dans la vie d'un projet de logiciel libre !

Alors enlightenment_remote n'a pas disparu, il existe toujours sauf que aujourd'hui, le code est nettement plus maintenable grace a l'utilisation de dbus. Le probleme, c'est que seul les fonctionnalites qu'utilisaient les devs ont ete remise dedans... Et c'est un peu pas de chance pour ton utilisation. Et ton ticket tape exactement la ou le bas blesse dans E17, les interfaces de config pas vraiment ergonomique.

Le fait est aussi, qu'on a tendance à ne pas regarder souvent le bug tracker. Perso, c'est quand je recois les mails du bug tracker que je regarde si je peux le fixer vite fait, si ce n'est pas possible, souvent je n'y reviens pas... Et ca, c'est tres mal. Donc je conseille de refaire un petit ping sur le bug tracker de temps en temps pour demander ou ca en est. Ca reenverra d'ailleur un mail a tous les devs augmentant d'autant la possibilite qu'ils s'en occupent :-)

Oui, alors bon, les standards Freedesktop, c'est le premier qui propose qui gagne. Rien a voir avec la valeur technique du truc ou de son utilisabilite et a ce jeu, GNOME, ils sont tres fort... Malheureusement !

Juste une question, on va faire comment pour "sortir du nucleaire" ? J'espere pas comme les Allemands. Car en coupant leurs centrales, ils ont besoin d'en racheter chez nous en quasi permanence. En contre partie pour tenir nos objectifs de CO2, ont achete lors des piques de l'electricite chez eux... qui est faite a base de gaz, petrole, charbon.

Une grande reussite, nous tenons nos objectifs de non pollution au CO2 et les allemands tiennent leur objectif de sortir du nucleaire en deplacant le probleme chez l'autre !

Donc si on veut vraiment sortir du nucleaire, va falloir franchement se motiver et trouver des solutions avec un ordre de grandeur jouable. On peut deja oublier l'eolien. Les deux seules sources d'energie potentiel, la geothermie et le solaire. Il y a apriori un fort potentiel de geothermie en france inexploite et certain chiffre tel qu'une diminution de 80% de l'energie de chauffage de nos vieux immeubles des annees 60/70 (couple a de l'isolation) semblent envisageable. Le solaire quand a lui offre une source d'energie abondante et stockable sous forme de chaleur, malheureusement pour avoir des rendements suffisant et interressant il faut aller s'installer dans le sahara. Certain projet tel que Desertec l'envisage, mais il y a quand meme des risques geopolitiques assez fort.

Il n'y a donc pas forcement de reponses simple a cette problematique. Et puis dans le fond, le plus urgent, c'est de sortir de l'age de l'or noir. Ca nous coute chere, polue la planete et fait peser un risque geostrategique majeur sur notre societe...

Ca devrait repondre a tes questions : http://www.cpubenchmark.net/cpu_list.php

En général, les gens de GNOME démarrent la discussion AVANT ou au DEBUT d'implémenter la spécification, ce qui est plus logique.

Alors ca, ca me fait sauter au plafond ! Et ca explique plein de chose concernant la pietre qualite des standards Freedesktop ! Si tu tentes de definir un standard sans avoir jamais code au minimum un proof of concept, tu n'as pas idee de ce qui va techniquement te poser des problemes. Il faut deja avoir du code et de l'experience dans le domaine d'un standard pour avoir une chance de faire quelque chose d'efficace, peren et utilisable !

Ca ressemble plus a la maniere de se comporter quand on doit legalement assurer du support a des boites externes tout en voulant faire mourrir les investissements internes. J'ai deja vu ca dans deux boites en france, tu refiles un produit developpe en interne a une societe de presta et progressivement tu coupes les vivres en interne. Resultat, les plus motives bascule dans la ssii pendant que l'engagement de la societe principale disparait progressivement. J'espere que ce n'est pas ca, car ca ne serait pas de bon augur pour Qt...

Je te conseille la lecture complete de cette page : http://trac.enlightenment.org/e/wiki/EFLOverview qui t'expliquera toutes les differences entre un toolkit moderne et des toolkits plus ancien. Elle est longue et dense, mais il y a tellement de concept different a presenter qu'il n'y a pas le choix.

Et oui, il y a vraiment des differences fondamentales dans la maniere de gerer le pipeline graphique avec les EFLs. Oui, chaque composant est etudie pour etre le plus efficace possible.

Tu as donc regarde la main loop, c'est a dire la bibliotheque Ecore, tu as donc note la presence d'idler (enterer, exiter), d'animator et de poller. Chacun de ces types de timer ont leur utilite. Ainsi l'idler enterer sert a declencher le rendu du canvas, car c'est a ce moment la que Ecore sait qu'il n'a plus rien a faire et donc que le canvas est dans un etat stable et donc qu'on peut faire le rendu. Il n'y a donc pas de rendu intermediaire, on ne voit pas la fenetre se construire. Les animators eux sont tous execute de maniere synchronise a la vitesse des fps du systeme. Cela permet d'avoir toutes ses animations de maniere synchro. Cela peut paraitre trivial dit comme ca, mais certain toolkit ont quand meme des animators qui ne sont pas synchronise, ce qui fait qu'au lieu d'avoir une application qui doit fonctionne a 60fps, tu as une application qui tente de tourner a n * 60fps ou n est le nombre d'animator. Je te laisse imaginer les problemes que cela pose... Enfin les pollers sont des timer imprecis qui s'on appele lorsque d'autre timer ou evenement reveille le systeme. Cela evite de reveiller le systeme pour savoir l'etat de la batterie par exemple et profite plutot que le systeme est reveille pour faire cette tache.

Tout cela concour a ce que la mainloop propose de nombreux mecanismes pour simplifier l'ecriture d'une application optimale et consommant effectivement moins de batterie. Mais clairement la main loop est une tache trivialle et ce n'est pas la que se passe les optimisations qui offrent le plus de gain. Evas est veritablement le coeur du systeme et de son design vient reellement la difference par rapport aux autres toolkit. Comme explique plus en detail sur le lien que j'ai mis en haut de cette page, le fait que l'on manipule des objets sur le canvas et non qu'on peigne dessus directement offre d'enorme facilite d'optimisation qu'aucun toolkit aujourd'hui ne peut mettre en place. C'est une difference architecturale majeur. Si tu ne me crois pas, je vais te referer au blog QT de Zack Rusin qui decrit comment il pense implementer ca dans QML et Webkit: http://zrusin.blogspot.com/2010/11/2d-musings.html .

Il est suffisament fini pour etre utilise par la societe Ordissimo dans les ordinnateurs qu'elle fournit a des personnes qui decouvrent l'informatique. Donc oui, il est toujours en developpement, mais il est deja bien utilisable.

Ce n'est pas parce qu'on release quelque chose que c'est utilisable et inversement ce n'est pas parce qu'on ne release pas quelque chose qu'on ne peut pas l'utiliser. La problematique d'une release impact uniquement les developpeurs, car une release implique une stabilite des interfaces de developpement et tres peu finalement les utilisateurs.

Les EFL ne sont pas un logiciel, mais une bibliotheque stable et utilisable, mais peu utiliser. La finition des EFLs en tant que tel est d'un tres bon niveau et largement comparable a ce que fournit Qt et GTK. Et ce n'est pas une demo technique, tu peux des aujourd'hui developper une application avec et obtenir une application fini, propre avec.

Pour ce qui est de tourner sur ton PC, je crois que tu te meprends sur l'objectif des EFLs. La plus part des devs utilisent les EFLs dans l'embarque, et c'est le premier objectif aujourd'hui, car c'est la qu'il y a un marche a prendre et ou rien n'est joue. Sur le desktop, Linux est une niche de petite taille ou il y a deja 3 desktops qui se battent (kde, gnome, lxde). Et il n'y a aucun interet a recreer ce qui existe deja. Ca n'apporte rien au monde du libre.

Maintenant, si tu veux quelque chose pour toi, sur ton pc, et bien les EFLs peuvent te permettre de le developper et tu ne rencontreras aucune limite quelque soit le materiel que tu as.

Note: Free n'utilise que la version mainstream du svn du projet Enlightenment et les sources sont donc completement publique.

Le property bindings, c'est justement un des trucs qui pose probleme en terme de perf, car tu peux mettre n'importe quelle expression JavaScript. Alors que au fond pour 80% voir meme 100% des cas, le positionnement relatif suffit. En plus ca simplifie beaucoup ton code de juste donner une reference sur un autre objet plutot que de partir dans des formules compliquees.

Donc Edje fait que du positionnement relatif avec offsets, car il faut bien pouvoir prendre en compte des bordures ou d'autre petit decalage. Et c'est tout, cela permet de rendre une interface edje fonctionnelle quelque soit la resolution sans se compliquer la vie sur des formules de math. Pas d'effort du cote du designer pour mettre en place une telle solution.

Juste pour qu'on soit d'accord sur les affirmations techniques, les EFLs sont toujours plus performante que QML/CoreAnimation/... whatever. J'ai bien precise que le seul toolkit qui avancait dans la bonne direction etait QML avec le backend SceneGraph. Mais c'est loin d'etre comparable pour l'instant !

QML necessite l'utilisation d'un ou plusieurs contextes JavaScript qui posent de gros probleme en terme de consomation CPU et limite les optimisations possible. Le second probleme, c'est que QML devient un langage de programmation complet... Ce qui fait qu'il devient facile pour le developpeur de melanger interface et logique applicative, ce qui fini par rendre une application moins evolutive, themable et maintenable. De plus le gain en terme de ligne de code n'est pas evident. A tout ces problemes, les EFLs ont deja des solutions qui marchent aujourd'hui.

De maniere plus general, ce n'est pas parce que tu es capable d'animer un widget que tu as une solution equivalente. Ainsi il te faut du matos plutot chere pour faire tourner Android, QT, iOS. Alors qu'avec les EFLs, tu peux des aujourd'hui attaquer le marche avec du materiel, beaucoup, beaucoup moins chere et tout de meme offrir une experience utilisateur sympa.

Pour ce qui est de la richesse/qualite des outils de devs, je pense qu'il manque un editeur graphique de fichier edje pour simplifier la vie au designer. Si tu parles de la richesse de l'API pour les devs, tu peux aujourd'hui developper un bon nombre d'appli sans etre bloque.

De maniere plus generale, la bataille dans l'embarque ne fait que commencer. Faire des terminaux graphiques en entree de gamme sans sacrifier l'experience utilisateur n'est pas un probleme simple.

Alors a ma connaissance, il y a la technologie Flex qui pourrait permettre a Adobe d'implementer le meme type de fonctionnalite, mais malheureusement on va dire qu'ils ont de petite difficulte a fournir une solution performante...

Sinon dans l'embarque leur solution s'appelle Flash Lite qui est juste une version de Flash avec beaucoup de truc en moins sans vraiment avoir un coeur plus performant.

A l'heure actuelle la seule technologie qui se rapproche de ceux que font les EFL, c'est QML avec le SceneGraph (Meme si celle-ci est beaucoup plus jeune est moins abouti). Sinon pour avoir une comparaison plus logique, les moteurs de rendu de jeu 2D sont ceux qui ont le plus de proximité avec ce type de pipeline de rendu.

Pour faire simple, c'est le fait d'avoir en un point toutes les informations sur ce qui doit etre rendu a l'ecran qui permet de faire de tres nombreuses optimisations et de tirer partie du materiel au mieux (C'est le boulot de la bibliotheque Evas). Ensuite les EFL fournissent aussi un moyen propre et clair de separer description de l'interface, animation et logique applicative grace a la bibliotheque Edje.

Enfin les EFL ont ete concu dans un unique but, etre le plus efficace possible en terme de CPU et de consommation memoire tout en etant graphiquement le plus joli et anime possible. Ainsi des le depart la cible a ete l'embarque, j'en veux pour preuve cette demo: http://www.rasterman.com/files/eem.avi , qui tournait sur un iPaq en 2004...

Autre remarque, les prestataires de SSII ne rentrent pas dans le calcul du nombre de salarie, mais directement dans la colonne depense R&D le plus souvent. Resultat, on fait croire qu'on reduit le nombre de salarie en augmentant la R&D de nouveau produit, de quoi faire plaisir a l'actionnaire. Le probleme, c'est que dans la pratique, on a un enorme turn over de prestataire qui vont et viennent a la concurrence...

De toute facon, il ne faut jamais avoir developpe sur un terminal Symbian pour croire que ca a un avenir ! Mais ils ont malheureusement mis trop de temps a l'admettre (politique, politique...) Et a mon avis, c'est ca qui leur a ete vraiment fatal. En etre en 2011 et ecore essayer de faire vivre cette plateforme, c'est juste une aberation !

Forcement il y a des briques proprietaires, mais il y deux groupes.

D'abord celle des pilotes de drivers lie a la stack radio et au accelerateur hardware disponible dans le SoC, qui sont generalement proprietaire dans toutes les SoC. Je ne pense que demain sera disponible un SoC avec des drivers libres d'un bout a l'autre. Et meme si j'ai peut-etre tort, ca n'a que peu d'impact pour le soft qu'ils l'utilisent, car l'API ne changera pas entre les deux.

Ensuite, les applis natives proprio, mail, sms, ... Celle-la, tu peux les reecrirent en libre, et le status est le meme que sur un terminal Android a ma connaissance.

Alors oui, il y a des morceaux de non libre, ca serait tellement mieux si il n'etait pas la. Mais a court terme, il n'y a pas vraiment de solution pour s'en passer et avoir un GNU/Linux et pas un Google/Linux...

Meego dans les telephones, c'est quand meme serieusement compromis ! Intel n'a pas prevu de faire un telephone a court terme...

Peut-etre un Samsung alors :

http://marc.info/?l=enlightenment-devel&m=12974460272543(...)

La date prevu pour un produit avec LiMo est pour le second quarter d'apres ces slides. Pas trop long a attendre... Mais un bon moment pour regarder les EFL !

En tout cas, pas par les clients !

En meme temps, il n'y a plus grand monde qui fait que de la 2D dans son rendu. Les coverflow et autre effets a la Apple sont autant de cas qui forcent les differents toolkit a soit a fournir un hack complique pour que ca marche avec Xrender, soit a faire uniquement la chose avec un backend opengl et ignorer Xrender, soit cas rarissime a implementer tout en soft et en opengl, mais aussi a ignorer Xrender dans ce cas.

En fait, les performances de Xrender sont en general tres mauvaise et une implementation soft est tres tres souvent plus rapide qu'un implementation Xrender (Je dis tres tres souvent, c'est juste pour eviter l'exception qui confirme la regle).

Au final, l'histoire ce sera OpenGL, OpenGL ES plus un moteur soft. Le reste disparaitra. En plus c'est portable entre toutes les archis assez facilement.

J'ai aussi un 701, depuis mon install d'une arch et l'utilisation de e17, je l'utilise tous les jours sans probleme ni de performance ni d'usure et ca depuis le premier mois de sa sortie !

Le soft fait bcp qd a l'utilisabilite de ces machines !

En fait, c'est oublie l'histoire de Wikileak. Leur premier leak, c'etait ca, la mise a disposition de fichiers sur un site web et quelques blogs... Et ca a fait plouf, les medias ne l'ont pas repris !
C'est pour ca que Wikileak travaille sa "marque", et fait le buzz avec des journaux traditionnels en creant la rarete et controlant la diffusion. Tu peux tenter de twitter/blogger autant que tu veux, les infos n'arriveront probablement jamais dans les medias. Il n'y a qu'a voir le temps qu'a mis un truc comme le Foreclosuregate a passer du blog a la presse specialise, et qui n'est toujours pas passe dans les grands medias...