Il se passe quoi si le serveur ferme ou tombe en rade. J'ai toujours acces a ma bibliotheque ou j'en perd des morceaux ? Ca veut aussi dire que je ne peux pas deplacer ou auto heberger ma synchronisation, ni mes livres d'ailleur.
Que la synchronisation soit fait sur le serveur, ca peut etre pratique, que l'application et les donnees n'en soit pas independente, ca peut etre genant dans le temps. Par contre, c'est deja mieux que la demarche d'Amazon.
Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher. C'est un "lege" probleme. Plus cosmetic, quand tu switch d'un utilisateur a un autre, c'est lent et c'est pas beau !
En ayant un top compositeur qui se charge de ca, tu peux regler les deux problemes. D'un point de vue performance ce top compositeur sera surement la plus part du temps dans le mode je switch les buffers du seul fils que j'ai. Donc ca coutera un switch de context, mais ca sera tout. Si ce compositeur est garde simple, il sera donc une source de plus grande stabilite et d'interface plus sympatique. Ca ressemble au progres pour moi.
Le travail va effectivement etre plutot important pour tous les Window Manager qui n'ont pas de Composite Manager et qui n'utilise pas un toolkit supportant l'ecriture de composite manager. Peut-etre apparaitra-t'il des hacks dans Weston pour brancher leur logique, mais la tache n'est pas negligable pour eux.
J'ai pas l'impression que tu es jamais participe a l'elaboration d'un standard ni meme tente d'en implementer un. Ils arrivent tres tres frequement qu'un standard soit defini par une societe unique qui tente de le forcer sur les autres, car elle y trouve son intret. Mais un standard n'a de valeur que si tous les acteurs acceptent de le suivre. Donc il y a une limite d'acceptabilite qui fait que certain standard n'arrive jamais a perce, car ils sont effectivement trop moisi.
Personnellement, je trouve 2s sur une machine recente insupportable. Je peux demarrer un toolkit complet en 80ms sur un cortex A8. Quand je clique sur une icone, je veux que avant que mon doigt est quitte le bouton, avoir l'application a l'ecran. Les splash screens etant a mon sens l'aberation ultime d'une application. Et oui, je concois que des fois, on passe du temps a charger plein de module comme GIMP, mais pourquoi je ne peux pas en meme temps commencer a manipuler mon application et avoir un chargement asynchrone…
J'ai un laptop qui avec un noyau un peu tune boot en 2s jusqu'au gestionnaire de fenetre, si une application prend dessus plus de 1s a se lancer, c'est inacceptable de mon point de vue.
Je vie dans un pays ou je rencontre un Francais tous les quinze jours. Mon clavier n'a aucun accents et 90% des gens avec qui je communique journalierement ne parle pas francais. Donc non, je prends pas le temps de gerer les accents pour les peu de fois ou j'ecris en Francais. Faut pas croire que tout le monde vit et parle en Francais. Il y a un monde en dehors de la France…
On est donc beaucoup plus productif en C++ qu'en C.
Question d'habitude :-) Et j'ai vu assez de code C ecrit en C++ pour te dire que la tres grande majorite des devs "C++" ne saient pas en faire ni en tirer benefice. Maintenant, tu prend un developpeur experimente en C ou en C++, je pense qu'ils auront la meme productivite. Quand au cout du C++, il y en a un que tu ne peux meme quand tu es bon eviter, c'est le link. Le nombre de symbole dans les libs C++ etant juste dantesque, tu te retrouves avec des temps de demarrage hallucinant et non ameliorable. Pour le reste, quelqu'un qui connait tres bien le compilo et comment le modele objet du C++ fonctionne sera tout a fait capable d'avoir les meme perfs qu'en C, je n'en doute pas.
Quand on a envie d'utiliser le C++ pour être productif, on aime utiliser des API en C++. On aime pas utiliser le C.
De mon point de vue, le C++ donne un gain a cour terme, mais avec le temps, en tout cas pour tous les projets industriels que j'ai vu, ca tend vers le rustinage et l'horreur de maintenance. Et plus le turn over de l'equipe est important, plus cela tourne au cauchemar. C'est juste une conclusion de mes observations. Maintenant, si tu as une petite equipe stable de 4, 5 personnes, le resultat peut etre tres impressionant dans le temps. Mais c'est rarement un cas qui arrive dans la pratique (a part pour certain projet libre qui tende a maintenir un equipe core stable sur de longue periode).
Et j'ai aussi utilise l'API C et C++ de LLVM, le fait quel marche ou pas, et completement anecdotique vu qu'on a les source (on peut resoudre les bugs facilement). Maintenant la version C++ a eu une vie plus courte que la version C…
Hahaha, mais bien sur, et C++ tues aussi plus de bébés chat que le C. Et le C permet de meilleur performences sexuelles. C'est prouvé :-)
Oh ! J'ignorais tout ca, cool ! Plus serieusement, entre l'utilisation des objets a tout va, des templates, des allocations "caches", la tendance est a l'embonpoint. Le fait que beaucoup d'operation memoire soit implicite, fait que si on manque d'attention, ca consomme vite plus. Dans la theorie, tu dois pouvoir arriver au meme en faisant attention, dans la pratique peu de projet y arrive, car il faut etre vraiment tres tres conscienceux.
Euh.. GTK aussi change son API. GTK2 à duré 9 ans. et Qt4 8 ans.\
D'apres ma memoire, l'ABI du C++ a ete casse avec gcc 4.2 en 2007, donc ca peut pas faire 8 ans ou alors tu m'ecris du futur.
Simplement GTK n'utilise pas un canvas de rendu statefull pour ces widgets ou scene graph. Cela rend impossible toute amelioration de performance un tant soit peu pousse. De plus, le nombre de contributeur a GTK est actuellement bas, et c'est un fait. Coder ce genre de chose est tres difficile. Et non, il ne suffit pas de mettre tout ca dans des textures et balance ca un GPU pour que ca fasse un gentil tour de magie.
Je suis tellement pas d'accord avec toi, aussi bien sur ton analyse technique que sur les objectifs de ton message que je ne sais meme pas par ou commencer. Disons la technique.
Donc commencons par Qt, honneur au plus age. Qt existe depuis une epoque ou le C++ n'etait pas portable avec la STL et qu'il etait difficile de trouver un compilo qui s'en sorte avec. Cela explique beaucoup de chose dans son design. Apres il y a une faute fondamentale pour un toolkit. Il y a une regle, qu'ils ont decouvert que trop tard dans leur histoire, si on veut fournir une API/ABI stable au cour du temps, on utilise le C. Le C++ qui a du mal a avoir une ABI stable pose deja un probleme de base, mais le fait que les champs prives finissent dans les headers rend impossible de fournir la moindre stabilite a long terme. LLVM l'a bien compris, seul l'api C sera stable. Cette erreur est a mon gout fatale pour un toolkit. On peut rajouter que le C++ a aussi un coup d'utilisation CPU et memoire superieur a du C, mais c'est globalement irrelevant pour cette discussion.
GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme. Par contre, le design meme de l'architecture de ce toolkit pose de gros probleme de performance et d'efficacite, hors dans un monde ou tout se dirige vers l'embarque, GTK se revele completement inadapte. Les evolutions de ce toolkit ont essaye de combler le probleme, mais ca releve plus de la rustine que d'une veritable solution. Ce qui tend a rendre ce toolkit obsolete (et par la meme, la desaffection des developpeurs du coeurs du biniou).
Maintenant tu prend en exemple Chrome parce que eux, ils n'ont pas pris de toolkit, donc ils s'en sortent mieux que Mozilla. Comment dire, c'est une excuse facile ! Deja les problemes d'integration et les bugs de Chrome sont nombreux. Copier/Colle qui foire une fois sur deux, le rendu des textes dans un autre alphabet que occidentale qui sont loufoque, … Pour Mozilla, le principal probleme a mon sens c'est leur code source et leur gestion de la communaute. Je n'ai regarde que le code de SpiderMonkey et consort, mais c'est vraiment calamiteux et la communaute des developpeurs autre que Mozilla a vraiment du mal a participer (voir meme a juste utiliser leur techno). Ca s'explique par l'age de la bete, mais quand on voit v8 ou WebKit, c'est une tout autre histoire… Faudrait commencer par faire le menage chez soi avant d'accuser les toolkits de pas vous aider.
Dans le meme genre, tu peux prendre aussi LibreOffice/OpenOffice qui ont aussi leur propre toolkit. Une vrai bouse qui rame et prend son temps meme avec un i7, des Go de ram et un SSD. Et je parle meme pas de l'integration correct a X (l'integration correct au desktop kde/gnome etant trop loin…). Developper son propre toolkit, ca donne ca. Des couts de developpement supplementaire, des erreurs de design, car on n'a pas l'experience des gens qui font des toolkits donc on "loupe" des trucs. Et avec le temps ca ralentit completement le developpement d'un projet en augmentant la masse de developpeur necessaire pour le maintenir en vie. Surtout que l'excuse le toolkit, il fait pas ce qu'on veut ou ils cassent tout dans le temps, c'est vraiment petit quand on est une societe avec les moyens ou un gros projet libre. On peut influencer voir participer (concept nouveau dans le logiciel libre) dans le developpement des projets utilises en dependences. Vraiment une idee de fou.
Enfin sur le fond, ton message est de dire que c'est la faute au toolkit si Linux n'a pas pris sur le desktop. Qu'il n'en faut que un pour que l'on reussisse a s'imposer. Bah meme si on avait eu un super toolkit de la mort qui tue, unique, performant, joli, portable, lege et stable pour les 50 ans a venir, on n'aurait pas plus pris de part de marche sur le desktop. Regarde juste Apple, ils n'arrivent sur le desktop que par le cote (les vents d'ipod, iphone et ipad drivant les ventent de matos) et malgre tout ca, ils en sont a 7 ou 8% de part de marche mondial. Oh, et ils ont aussi un toolkit unique et du beau matos. Le probleme du desktop, c'est qu'il y a une arme de milliard d'individu et de societe refractaire a tout changement qui ne changeront jamais leurs habitudes. La strategie de l'attaque frontale, genre troll qui fonce dans le tas, c'est sur c'est heroique, ca fait un beau film d'action et de sympathique scene de bataille. Mais a la fin, le troll, il meurt. Il faut toujours s'installer la ou l'ennemie n'est pas, se fortifier et s'etendre. Et uniquement a la fin attaquer la cible principale, si elle existe encore.
De plus, tu pars du principe qu'avoir des applications isolees, des iles qui echangent des donnees de temps en temps, c'est la solution. La preuve, Apple, Microsoft et le web font ca et ca leur reussi. Sauf que une des raisons pour la reussite de Gmail, c'est que tu as en meme temps, l'IM, le calendrier, la recherche, la preview de document, … Le tout bien integre. Parcontre, tu n'as plus le choix. Et globalement aucun lecteur de mail classique ne s'en approchent (a part Kontact, mais ils arrivent pas a gerer mes 7Go de mails). Tu loupes un pan entier de ce qui est l'objectif d'une partie des developpeurs du libre. Quand on a fait le deuil de la domination du monde, qu'on arrete de vouloir concurrencer des gens qu'on ne peut pas concurrencer. Alors ce pose la question de qu'est-ce qu'on peut faire mieux ? Qu'est-ce qu'on peut ameliorer par rapport a l'existant et qui attirera suffisamment de gens, plutot des developpeurs si possible, dans notre petite forterresse ?
La reponse que le libre a donnee a cette question, c'est l'integration quit a avoir 5 ou 6 desktop. C'est sur, ca correspond pas a Mozilla, qui vit dans un monde ou tout est isole et ou la communication entre chacun est limite. Mais et pour le coup, je trouve ce qu'a fait le projet KDE vraiment pas mal dans ce domaine. Ils n'ont rien standardiser pour la communication entre leurs applications, ils ont juste developpe leur technologie adhoc et integre joyeusement tout ca. Et je suis pas un developpeur de KDE, je participe au projet Enlightenment, mais ca m'empechera pas de reconnaitre les reussites des autres projets.
D'ailleur, j'ai oublie de faire ma charge sur les standards. C'est truc, c'est une calamite, suffit de regarder FreeDesktop, le jour ou j'y trouve un standard de qualite, bien ecrit, bien pense et utile, je t'offre le champagne. Les standards sont une maniere a un projet d'imposer ses choix a un autre en etant le premier a ecrire la spec, car les temps entre les projets ne sont pas les memes. Il n'y a pas un expert en permanence disponible dans tous les projets de desktop pres a negocier n'importe qu'elle sujet de standard. Resultat, le standard, il se fait tout seul dans son coin et 6 mois plus tard on se rend compte qu'on veut implementer la meme feature, donc on regarde ce nouveau standard pour se rendre compte que c'est une catastrophe… Et on perd du temps a l'implementer de la maniere la moins catastrophique qui soit. Forcement c'est encore une solution a minima qui aide personne et impact tout le monde.
Developper ce genre de bibliotheque peut se resumer a dire que tu prends le plus petit commun denominateur et que tu vas avoir tous les inconvenients de tous les toolkits sans aucun avantage. De toute facon, tu ne pourras pas integrer des applications plus que visuellement (partager des informations, des liens, …). Et puis, je ne peux pas m'empecher de mettre un lien vers : http://xkcd.com/927/ .
Il y a des pays qui ont parfaitement su organiser des faillites bancaires. Ça s'appelle la méthode serbe d'ailleurs. Le problème n'était pas le liens des états avec les banques, mais des politiques avec les banques.
Les ladas, c'était mieux ! L'informatique est aussi une grande réussite du public…
Va donc voir en Corée du nord ce que l'économie planifié permet. L'implication des états dans l'économie est en générale assez lamentable (problème de copinage, protection de sa prochaine élection, manque de compétences pour anticiper, dépense de l'argent des autres,…). Dans le privé la société coule, les investisseur gèrent leur pertes et les salarié changent de société. Quand un état déconne, ça devient plus compliqué, mais on aura des demos grandeur réelle bientôt…
On a reconnu l'existence de 3 pouvoir, on a oublié le pouvoir économique, dommage lui il n'a pas loupe le coche et environ 60% du pib est reversé par l'état…
Nop, car tu n'as pas dans certain cas besoin de repasser par le compositeur. Le client fait tout le rendu, ça évite une grosse copie dans le compositeur plus un rendu complet du reste de l'écran.
Les décorations coté client, j'ai toujours du mal a me faire a cette idée. Mais il faut dire qu'elle apporte un gain de performance non négligeable dans pas mal de cas. Le compositeur pouvant directement donner la surface du client ala carte graphique au lieu de le 'compositer' avec le gpu. En gros ça peu permettre sur mes benchmark un gain de 30% (ou 30% d'économie d'énergie ). C'est juste un exemple, il y a pas mal d'autres cas ou ça aide: rotation, fenêtre non rectangulaire,…
Il n'est pas possible dans le protocol Wayland pour une application de prendre un screenshot de l'ecran (ce qui pose de gros probleme de securite sous X). Par contre l'implementation du compositeur Wayland, par exemple Weston, peu tout a fait faire un screen shot de l'ecran sans probleme. D'ailleur elle peut meme te generer une video avec un format qui detecte d'emble les deltas a l'ecran.
Tu peux maintenant acheter les anciens numéro en PDF, très utile quand tu vis a l'étranger et les anciens numéro publié sous licence créative common son aussi mis en ligne sur le site. Le choix de la licence dépendant de l'auteur.
Thunderbolt actuellement fonctionne avec un cable cuivre pour le signal et deux puces actives dans le cable lui meme pour compenser le bruit dans le biniou. L'evolution est de passer a une fibre optique pour le signal. Mais il y aura donc toujours deux puces, mais cette fois-ci pour la convertion optique. Par contre un cable thunderbolt fournit aussi une alimentation, donc il garde une partie de sa connectique cuivre pour ca. Dans l'ensemble, je dout qu'il y ait une difference de prix entre les cables cuivre et optique a l'avantage de l'optique.
L'idee du PoE est sympa en fait. Suffit de mettre un hardware qui consomme moins de 25W. Les hard de tablette le font et une partie des procs d'Intel annonce devrait aussi le permettre. C'est une idee interressante.
Thunderbolt implique des cables actif (avec une puce de chaque cote). Le cout ne vient pas du cuivre, mais des puces a chaque bout du cable. Intel doit fournir une nouvelle generation avec une plus grande finesse de gravure et donc un prix par composant inferieur qui pourrait solutionner le probleme. Il y a avait un article sur le sujet sur Arstechnica, si je ne me trompe pas.
Si j'ai bien compris l'annonce, c'est juste pour faire le prototype. L'experience utilisateur dependra tres fortement du SoC qu'ils vont choisir. Vu le prix cible, je doute que ca soit grandiose etant donnee les besoins de Ubuntu…
Pour une societe qui va produire un telephone "from scratch" avec le design hard, soft et l'equipe de commerciaux/marketing necessaire. Tu as besoin de 30 a 50 personnes. Les premieres annees, tu vends peu voir pas, donc faut du cache pour nourrir tout le monde, faire les prototypes et les premiers batch de production. Globalement en dessous de 15 millions d'euros, tu tiens pas avant que le concept prenne. Par contre, le fait de le faire sur un kickstarter like aide pour le marketing. J'espere qu'il a d'autre investisseur…
C'est encore limite comme concept. Les applications Android ne permettant pas d'etre partage avec l'environnement Ubuntu. Je suis pret a parier que actuellement une partie de la communication entre les applications messagerie instantane, reseaux sociales et voir meme peut etre mail, se fait encore via le cloud :-)
Mais c'est clairement le chemin de l'avenir. Pourquoi avoir 4 unites centrales, quand seul 4 ecrans sont necessaires. Pourquoi s'embeter a avoir 4 systemes d'exploitation qui communiquent moyen entre eux. Pourquoi est-ce que je suis oblige de renouveler tous mes peripheriques des que je veux une nouvelle generation d'OS… La liste est longue et les gains potentiels important.
Posté par cedric .
En réponse au journal udev forké.
Évalué à 4.
Non, je ne rigole pas. Les gens ne veulent pas entendre la realite. Ils ne veulent pas qu'on leur parle des contraintes du monde reel. Il faut leur vendre du reve et celui qui leur raconte les bobards les plus proches de leurs aspirations se fait elire. Le principe est de bien connaitre son electorat, savoir qu'elle partie de la population choyer pour maximiser ses votes et se faire elire. J'ai arrete de croire aux bisounours, il y a quelques annees deja !
Il n'y a rien a attendre de la politique, ni du gouvernement.
Quand tu regardes l'architecture de Wayland, tu peux justement séparer les différentes briques : Window Manager, Display Manager, Composite Manager, Events Manager, etc.
Non, tu ne peux pas. L'event manager ne peut pas savoir ou envoyer un event, car seul le composite manager sait ce qu'il y a l'ecran a cette endroit la et a qui envoyer l'information. De la meme maniere d'un point de vue securite quand tu auras une fenetre demandans un mot de passe, il faudra une cooperation sans man in the middle entre le window manager, l'event manager et le composite manager. Techniquement tu ne pourras pas les separer. Et ca n'a jamais ete l'objectif.
seul le code sera structuré.
Tres grand innovation technique de Wayland d'ailleur :-D Non, franchement, c'est juste pour avoir raison que tu dis une telle generalite ou tu avais une vrai idee derriere la tete ?
Tout comme l'architecture d'X ne t’empêche pas de regrouper le gestionnaire de fenêtre, le composite manager et le server d'affichage dans un seul processus comme ce que fait Weston.
C'est d'ailleur un tres bon point que tu releves. Wayland aurait pu etre prototype quasiment completement dans X. Mais l'avantage majeur, pour les developpeurs de X, c'est de repartir d'une base de code propre. Et il faut pas oublier que pour l'instant Wayland est code par les developpeurs de X principalement (ca explique les incongruites qu'ils font dans le cote window manager…).
[^] # Re: Pas un simple logiciel de lecture
Posté par cedric . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 4.
Il se passe quoi si le serveur ferme ou tombe en rade. J'ai toujours acces a ma bibliotheque ou j'en perd des morceaux ? Ca veut aussi dire que je ne peux pas deplacer ou auto heberger ma synchronisation, ni mes livres d'ailleur.
Que la synchronisation soit fait sur le serveur, ca peut etre pratique, que l'application et les donnees n'en soit pas independente, ca peut etre genant dans le temps. Par contre, c'est deja mieux que la demarche d'Amazon.
[^] # Re: Gestionnaire de sessions
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 8.
Les consoles virtuelles sont implementes en cooperatif. Si ton serveur X est dans les choux ou tu as une appli frmebuffer un peu mal code, pas moyen de switcher. C'est un "lege" probleme. Plus cosmetic, quand tu switch d'un utilisateur a un autre, c'est lent et c'est pas beau !
En ayant un top compositeur qui se charge de ca, tu peux regler les deux problemes. D'un point de vue performance ce top compositeur sera surement la plus part du temps dans le mode je switch les buffers du seul fils que j'ai. Donc ca coutera un switch de context, mais ca sera tout. Si ce compositeur est garde simple, il sera donc une source de plus grande stabilite et d'interface plus sympatique. Ca ressemble au progres pour moi.
[^] # Re: Gestionnaire de fenêtres
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 3.
Le travail va effectivement etre plutot important pour tous les Window Manager qui n'ont pas de Composite Manager et qui n'utilise pas un toolkit supportant l'ecriture de composite manager. Peut-etre apparaitra-t'il des hacks dans Weston pour brancher leur logique, mais la tache n'est pas negligable pour eux.
[^] # Re: firefox et KDE : l'exemple
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
J'ai pas l'impression que tu es jamais participe a l'elaboration d'un standard ni meme tente d'en implementer un. Ils arrivent tres tres frequement qu'un standard soit defini par une societe unique qui tente de le forcer sur les autres, car elle y trouve son intret. Mais un standard n'a de valeur que si tous les acteurs acceptent de le suivre. Donc il y a une limite d'acceptabilite qui fait que certain standard n'arrive jamais a perce, car ils sont effectivement trop moisi.
[^] # Re: Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 4.
Personnellement, je trouve 2s sur une machine recente insupportable. Je peux demarrer un toolkit complet en 80ms sur un cortex A8. Quand je clique sur une icone, je veux que avant que mon doigt est quitte le bouton, avoir l'application a l'ecran. Les splash screens etant a mon sens l'aberation ultime d'une application. Et oui, je concois que des fois, on passe du temps a charger plein de module comme GIMP, mais pourquoi je ne peux pas en meme temps commencer a manipuler mon application et avoir un chargement asynchrone…
J'ai un laptop qui avec un noyau un peu tune boot en 2s jusqu'au gestionnaire de fenetre, si une application prend dessus plus de 1s a se lancer, c'est inacceptable de mon point de vue.
[^] # Re: Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -5.
Je vie dans un pays ou je rencontre un Francais tous les quinze jours. Mon clavier n'a aucun accents et 90% des gens avec qui je communique journalierement ne parle pas francais. Donc non, je prends pas le temps de gerer les accents pour les peu de fois ou j'ecris en Francais. Faut pas croire que tout le monde vit et parle en Francais. Il y a un monde en dehors de la France…
[^] # Re: Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1.
Question d'habitude :-) Et j'ai vu assez de code C ecrit en C++ pour te dire que la tres grande majorite des devs "C++" ne saient pas en faire ni en tirer benefice. Maintenant, tu prend un developpeur experimente en C ou en C++, je pense qu'ils auront la meme productivite. Quand au cout du C++, il y en a un que tu ne peux meme quand tu es bon eviter, c'est le link. Le nombre de symbole dans les libs C++ etant juste dantesque, tu te retrouves avec des temps de demarrage hallucinant et non ameliorable. Pour le reste, quelqu'un qui connait tres bien le compilo et comment le modele objet du C++ fonctionne sera tout a fait capable d'avoir les meme perfs qu'en C, je n'en doute pas.
De mon point de vue, le C++ donne un gain a cour terme, mais avec le temps, en tout cas pour tous les projets industriels que j'ai vu, ca tend vers le rustinage et l'horreur de maintenance. Et plus le turn over de l'equipe est important, plus cela tourne au cauchemar. C'est juste une conclusion de mes observations. Maintenant, si tu as une petite equipe stable de 4, 5 personnes, le resultat peut etre tres impressionant dans le temps. Mais c'est rarement un cas qui arrive dans la pratique (a part pour certain projet libre qui tende a maintenir un equipe core stable sur de longue periode).
Et j'ai aussi utilise l'API C et C++ de LLVM, le fait quel marche ou pas, et completement anecdotique vu qu'on a les source (on peut resoudre les bugs facilement). Maintenant la version C++ a eu une vie plus courte que la version C…
Oh ! J'ignorais tout ca, cool ! Plus serieusement, entre l'utilisation des objets a tout va, des templates, des allocations "caches", la tendance est a l'embonpoint. Le fait que beaucoup d'operation memoire soit implicite, fait que si on manque d'attention, ca consomme vite plus. Dans la theorie, tu dois pouvoir arriver au meme en faisant attention, dans la pratique peu de projet y arrive, car il faut etre vraiment tres tres conscienceux.
D'apres ma memoire, l'ABI du C++ a ete casse avec gcc 4.2 en 2007, donc ca peut pas faire 8 ans ou alors tu m'ecris du futur.
[^] # Re: Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
Simplement GTK n'utilise pas un canvas de rendu statefull pour ces widgets ou scene graph. Cela rend impossible toute amelioration de performance un tant soit peu pousse. De plus, le nombre de contributeur a GTK est actuellement bas, et c'est un fait. Coder ce genre de chose est tres difficile. Et non, il ne suffit pas de mettre tout ca dans des textures et balance ca un GPU pour que ca fasse un gentil tour de magie.
# Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 10.
Je suis tellement pas d'accord avec toi, aussi bien sur ton analyse technique que sur les objectifs de ton message que je ne sais meme pas par ou commencer. Disons la technique.
Donc commencons par Qt, honneur au plus age. Qt existe depuis une epoque ou le C++ n'etait pas portable avec la STL et qu'il etait difficile de trouver un compilo qui s'en sorte avec. Cela explique beaucoup de chose dans son design. Apres il y a une faute fondamentale pour un toolkit. Il y a une regle, qu'ils ont decouvert que trop tard dans leur histoire, si on veut fournir une API/ABI stable au cour du temps, on utilise le C. Le C++ qui a du mal a avoir une ABI stable pose deja un probleme de base, mais le fait que les champs prives finissent dans les headers rend impossible de fournir la moindre stabilite a long terme. LLVM l'a bien compris, seul l'api C sera stable. Cette erreur est a mon gout fatale pour un toolkit. On peut rajouter que le C++ a aussi un coup d'utilisation CPU et memoire superieur a du C, mais c'est globalement irrelevant pour cette discussion.
GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme. Par contre, le design meme de l'architecture de ce toolkit pose de gros probleme de performance et d'efficacite, hors dans un monde ou tout se dirige vers l'embarque, GTK se revele completement inadapte. Les evolutions de ce toolkit ont essaye de combler le probleme, mais ca releve plus de la rustine que d'une veritable solution. Ce qui tend a rendre ce toolkit obsolete (et par la meme, la desaffection des developpeurs du coeurs du biniou).
Maintenant tu prend en exemple Chrome parce que eux, ils n'ont pas pris de toolkit, donc ils s'en sortent mieux que Mozilla. Comment dire, c'est une excuse facile ! Deja les problemes d'integration et les bugs de Chrome sont nombreux. Copier/Colle qui foire une fois sur deux, le rendu des textes dans un autre alphabet que occidentale qui sont loufoque, … Pour Mozilla, le principal probleme a mon sens c'est leur code source et leur gestion de la communaute. Je n'ai regarde que le code de SpiderMonkey et consort, mais c'est vraiment calamiteux et la communaute des developpeurs autre que Mozilla a vraiment du mal a participer (voir meme a juste utiliser leur techno). Ca s'explique par l'age de la bete, mais quand on voit v8 ou WebKit, c'est une tout autre histoire… Faudrait commencer par faire le menage chez soi avant d'accuser les toolkits de pas vous aider.
Dans le meme genre, tu peux prendre aussi LibreOffice/OpenOffice qui ont aussi leur propre toolkit. Une vrai bouse qui rame et prend son temps meme avec un i7, des Go de ram et un SSD. Et je parle meme pas de l'integration correct a X (l'integration correct au desktop kde/gnome etant trop loin…). Developper son propre toolkit, ca donne ca. Des couts de developpement supplementaire, des erreurs de design, car on n'a pas l'experience des gens qui font des toolkits donc on "loupe" des trucs. Et avec le temps ca ralentit completement le developpement d'un projet en augmentant la masse de developpeur necessaire pour le maintenir en vie. Surtout que l'excuse le toolkit, il fait pas ce qu'on veut ou ils cassent tout dans le temps, c'est vraiment petit quand on est une societe avec les moyens ou un gros projet libre. On peut influencer voir participer (concept nouveau dans le logiciel libre) dans le developpement des projets utilises en dependences. Vraiment une idee de fou.
Enfin sur le fond, ton message est de dire que c'est la faute au toolkit si Linux n'a pas pris sur le desktop. Qu'il n'en faut que un pour que l'on reussisse a s'imposer. Bah meme si on avait eu un super toolkit de la mort qui tue, unique, performant, joli, portable, lege et stable pour les 50 ans a venir, on n'aurait pas plus pris de part de marche sur le desktop. Regarde juste Apple, ils n'arrivent sur le desktop que par le cote (les vents d'ipod, iphone et ipad drivant les ventent de matos) et malgre tout ca, ils en sont a 7 ou 8% de part de marche mondial. Oh, et ils ont aussi un toolkit unique et du beau matos. Le probleme du desktop, c'est qu'il y a une arme de milliard d'individu et de societe refractaire a tout changement qui ne changeront jamais leurs habitudes. La strategie de l'attaque frontale, genre troll qui fonce dans le tas, c'est sur c'est heroique, ca fait un beau film d'action et de sympathique scene de bataille. Mais a la fin, le troll, il meurt. Il faut toujours s'installer la ou l'ennemie n'est pas, se fortifier et s'etendre. Et uniquement a la fin attaquer la cible principale, si elle existe encore.
De plus, tu pars du principe qu'avoir des applications isolees, des iles qui echangent des donnees de temps en temps, c'est la solution. La preuve, Apple, Microsoft et le web font ca et ca leur reussi. Sauf que une des raisons pour la reussite de Gmail, c'est que tu as en meme temps, l'IM, le calendrier, la recherche, la preview de document, … Le tout bien integre. Parcontre, tu n'as plus le choix. Et globalement aucun lecteur de mail classique ne s'en approchent (a part Kontact, mais ils arrivent pas a gerer mes 7Go de mails). Tu loupes un pan entier de ce qui est l'objectif d'une partie des developpeurs du libre. Quand on a fait le deuil de la domination du monde, qu'on arrete de vouloir concurrencer des gens qu'on ne peut pas concurrencer. Alors ce pose la question de qu'est-ce qu'on peut faire mieux ? Qu'est-ce qu'on peut ameliorer par rapport a l'existant et qui attirera suffisamment de gens, plutot des developpeurs si possible, dans notre petite forterresse ?
La reponse que le libre a donnee a cette question, c'est l'integration quit a avoir 5 ou 6 desktop. C'est sur, ca correspond pas a Mozilla, qui vit dans un monde ou tout est isole et ou la communication entre chacun est limite. Mais et pour le coup, je trouve ce qu'a fait le projet KDE vraiment pas mal dans ce domaine. Ils n'ont rien standardiser pour la communication entre leurs applications, ils ont juste developpe leur technologie adhoc et integre joyeusement tout ca. Et je suis pas un developpeur de KDE, je participe au projet Enlightenment, mais ca m'empechera pas de reconnaitre les reussites des autres projets.
D'ailleur, j'ai oublie de faire ma charge sur les standards. C'est truc, c'est une calamite, suffit de regarder FreeDesktop, le jour ou j'y trouve un standard de qualite, bien ecrit, bien pense et utile, je t'offre le champagne. Les standards sont une maniere a un projet d'imposer ses choix a un autre en etant le premier a ecrire la spec, car les temps entre les projets ne sont pas les memes. Il n'y a pas un expert en permanence disponible dans tous les projets de desktop pres a negocier n'importe qu'elle sujet de standard. Resultat, le standard, il se fait tout seul dans son coin et 6 mois plus tard on se rend compte qu'on veut implementer la meme feature, donc on regarde ce nouveau standard pour se rendre compte que c'est une catastrophe… Et on perd du temps a l'implementer de la maniere la moins catastrophique qui soit. Forcement c'est encore une solution a minima qui aide personne et impact tout le monde.
[^] # Re: Une solution ?
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -1.
Developper ce genre de bibliotheque peut se resumer a dire que tu prends le plus petit commun denominateur et que tu vas avoir tous les inconvenients de tous les toolkits sans aucun avantage. De toute facon, tu ne pourras pas integrer des applications plus que visuellement (partager des informations, des liens, …). Et puis, je ne peux pas m'empecher de mettre un lien vers : http://xkcd.com/927/ .
[^] # Re: Privé moins cher ?
Posté par cedric . En réponse au journal L’aventure spatiale perd un peu de sa liberté. Évalué à 3.
Il y a des pays qui ont parfaitement su organiser des faillites bancaires. Ça s'appelle la méthode serbe d'ailleurs. Le problème n'était pas le liens des états avec les banques, mais des politiques avec les banques.
[^] # Re: Privatisation de l'espace
Posté par cedric . En réponse au journal L’aventure spatiale perd un peu de sa liberté. Évalué à 1.
Les ladas, c'était mieux ! L'informatique est aussi une grande réussite du public…
Va donc voir en Corée du nord ce que l'économie planifié permet. L'implication des états dans l'économie est en générale assez lamentable (problème de copinage, protection de sa prochaine élection, manque de compétences pour anticiper, dépense de l'argent des autres,…). Dans le privé la société coule, les investisseur gèrent leur pertes et les salarié changent de société. Quand un état déconne, ça devient plus compliqué, mais on aura des demos grandeur réelle bientôt…
On a reconnu l'existence de 3 pouvoir, on a oublié le pouvoir économique, dommage lui il n'a pas loupe le coche et environ 60% du pib est reversé par l'état…
[^] # Re: moi aussi
Posté par cedric . En réponse au journal Mon erreur sur Weston (le serveur de Wayland). Évalué à 2.
Nop, car tu n'as pas dans certain cas besoin de repasser par le compositeur. Le client fait tout le rendu, ça évite une grosse copie dans le compositeur plus un rendu complet du reste de l'écran.
# moi aussi
Posté par cedric . En réponse au journal Mon erreur sur Weston (le serveur de Wayland). Évalué à 3.
Les décorations coté client, j'ai toujours du mal a me faire a cette idée. Mais il faut dire qu'elle apporte un gain de performance non négligeable dans pas mal de cas. Le compositeur pouvant directement donner la surface du client ala carte graphique au lieu de le 'compositer' avec le gpu. En gros ça peu permettre sur mes benchmark un gain de 30% (ou 30% d'économie d'énergie ). C'est juste un exemple, il y a pas mal d'autres cas ou ça aide: rotation, fenêtre non rectangulaire,…
[^] # Re: noop
Posté par cedric . En réponse au journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland). Évalué à 3.
Tu n'as pas compris :-)
Il n'est pas possible dans le protocol Wayland pour une application de prendre un screenshot de l'ecran (ce qui pose de gros probleme de securite sous X). Par contre l'implementation du compositeur Wayland, par exemple Weston, peu tout a fait faire un screen shot de l'ecran sans probleme. D'ailleur elle peut meme te generer une video avec un format qui detecte d'emble les deltas a l'ecran.
[^] # Re: LWN et abo pour boite
Posté par cedric . En réponse au journal Un article sur la conception sécurisée des serveurs graphiques (X, Wayland). Évalué à 3.
Tu peux maintenant acheter les anciens numéro en PDF, très utile quand tu vis a l'étranger et les anciens numéro publié sous licence créative common son aussi mis en ligne sur le site. Le choix de la licence dépendant de l'auteur.
[^] # Re: transparence entre IP v6 et IP v4
Posté par cedric . En réponse à la dépêche IPv6 : des poules et des hommes. Évalué à 6.
J'ose esperer que tous les toolkits incluant un support reseau le font de maniere transparente. <pub>En tout cas, c'est le cas pour les EFLs.</pub>
[^] # Re: Plus d'Android ?
Posté par cedric . En réponse au journal Intel ne supportera pas Linux pour ses Clover Trail. Évalué à 1.
C'est bien pour ca qu'on parle du CPU pour tablette ici :-)
[^] # Re: Padfone / Motorola Webtop
Posté par cedric . En réponse au journal NexPhone : votre smartphone devient tablette, ordinateur portable et PC. Évalué à 3.
Thunderbolt actuellement fonctionne avec un cable cuivre pour le signal et deux puces actives dans le cable lui meme pour compenser le bruit dans le biniou. L'evolution est de passer a une fibre optique pour le signal. Mais il y aura donc toujours deux puces, mais cette fois-ci pour la convertion optique. Par contre un cable thunderbolt fournit aussi une alimentation, donc il garde une partie de sa connectique cuivre pour ca. Dans l'ensemble, je dout qu'il y ait une difference de prix entre les cables cuivre et optique a l'avantage de l'optique.
L'idee du PoE est sympa en fait. Suffit de mettre un hardware qui consomme moins de 25W. Les hard de tablette le font et une partie des procs d'Intel annonce devrait aussi le permettre. C'est une idee interressante.
[^] # Re: Padfone / Motorola Webtop
Posté par cedric . En réponse au journal NexPhone : votre smartphone devient tablette, ordinateur portable et PC. Évalué à 3.
Thunderbolt implique des cables actif (avec une puce de chaque cote). Le cout ne vient pas du cuivre, mais des puces a chaque bout du cable. Intel doit fournir une nouvelle generation avec une plus grande finesse de gravure et donc un prix par composant inferieur qui pourrait solutionner le probleme. Il y a avait un article sur le sujet sur Arstechnica, si je ne me trompe pas.
[^] # Re: Padfone / Motorola Webtop
Posté par cedric . En réponse au journal NexPhone : votre smartphone devient tablette, ordinateur portable et PC. Évalué à 4.
Si j'ai bien compris l'annonce, c'est juste pour faire le prototype. L'experience utilisateur dependra tres fortement du SoC qu'ils vont choisir. Vu le prix cible, je doute que ca soit grandiose etant donnee les besoins de Ubuntu…
Pour une societe qui va produire un telephone "from scratch" avec le design hard, soft et l'equipe de commerciaux/marketing necessaire. Tu as besoin de 30 a 50 personnes. Les premieres annees, tu vends peu voir pas, donc faut du cache pour nourrir tout le monde, faire les prototypes et les premiers batch de production. Globalement en dessous de 15 millions d'euros, tu tiens pas avant que le concept prenne. Par contre, le fait de le faire sur un kickstarter like aide pour le marketing. J'espere qu'il a d'autre investisseur…
[^] # Re: Padfone / Motorola Webtop
Posté par cedric . En réponse au journal NexPhone : votre smartphone devient tablette, ordinateur portable et PC. Évalué à 4.
C'est encore limite comme concept. Les applications Android ne permettant pas d'etre partage avec l'environnement Ubuntu. Je suis pret a parier que actuellement une partie de la communication entre les applications messagerie instantane, reseaux sociales et voir meme peut etre mail, se fait encore via le cloud :-)
Mais c'est clairement le chemin de l'avenir. Pourquoi avoir 4 unites centrales, quand seul 4 ecrans sont necessaires. Pourquoi s'embeter a avoir 4 systemes d'exploitation qui communiquent moyen entre eux. Pourquoi est-ce que je suis oblige de renouveler tous mes peripheriques des que je veux une nouvelle generation d'OS… La liste est longue et les gains potentiels important.
[^] # Re: la guerre de s unices
Posté par cedric . En réponse au journal udev forké. Évalué à 4.
Non, je ne rigole pas. Les gens ne veulent pas entendre la realite. Ils ne veulent pas qu'on leur parle des contraintes du monde reel. Il faut leur vendre du reve et celui qui leur raconte les bobards les plus proches de leurs aspirations se fait elire. Le principe est de bien connaitre son electorat, savoir qu'elle partie de la population choyer pour maximiser ses votes et se faire elire. J'ai arrete de croire aux bisounours, il y a quelques annees deja !
Il n'y a rien a attendre de la politique, ni du gouvernement.
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Non, tu ne peux pas. L'event manager ne peut pas savoir ou envoyer un event, car seul le composite manager sait ce qu'il y a l'ecran a cette endroit la et a qui envoyer l'information. De la meme maniere d'un point de vue securite quand tu auras une fenetre demandans un mot de passe, il faudra une cooperation sans man in the middle entre le window manager, l'event manager et le composite manager. Techniquement tu ne pourras pas les separer. Et ca n'a jamais ete l'objectif.
Tres grand innovation technique de Wayland d'ailleur :-D Non, franchement, c'est juste pour avoir raison que tu dis une telle generalite ou tu avais une vrai idee derriere la tete ?
[^] # Re: Tant que ça reste coté Desktop...
Posté par cedric . En réponse à la dépêche Le point sur udev et systemd. Évalué à 3.
C'est d'ailleur un tres bon point que tu releves. Wayland aurait pu etre prototype quasiment completement dans X. Mais l'avantage majeur, pour les developpeurs de X, c'est de repartir d'une base de code propre. Et il faut pas oublier que pour l'instant Wayland est code par les developpeurs de X principalement (ca explique les incongruites qu'ils font dans le cote window manager…).