Va falloir definir de quel type d'embarque dont tu parles. Parce que il y a une raison pour que OpenEmbedded utilise systemd depuis quelques temps ! Et dans le cas de machin trop petit pour systemd, tu vas franchement pas etre loin de devoir coder ton init tout seul…
Et de toute façon, je crois avoir remarqué que X n'a pas été pensé avec l'optique du multi-écran.
Tout a fait.
Le window manager, qui peut être composite ou non si je ne comprend pas trop mal les divers trucs que j'ai lus rapidement, est aussi un truc qui peut manifestement se coder en peu de lignes: dwm pèse moins de 2KLoC, je crois?
Pour un Window Manager simple oui. Pour un compositeur, meme simple, c'est deja un peu plus gros. Mais le probleme va se poser des que tu vas vouloir supporter un peu plus que juste les machines x86 (genre un backend specifique pour RPi ou n'importe laquelle des plateforme ARM en fait). La complexite explose tres rapidement de ce cote la. Ensuite si tu veux avoir des perfs decentes, tu vas devoir aussi optimiser pas mal ton compositeur, et forcement le nombre de ligne va augmenter. Au final, il sera tres difficile de refaire des tres petits WM comme sous X (Normal vu qu'il faut implementer une bonne partie de ce qui est dans X aujourd'hui).
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer.
Et y a t-il une quelconque raison technique qui rendrait ça impossible avec le présent protocole?
Principalement une volonte du mainteneur de Wayland/Weston qui ne voit pas d'utiliter a cela. Il pourrait changer d'avis un jour…
Par contre je me demande comment tu peux juger d'outils sans les avoir essayés?
J'ai pas du etre clair, mais j'ai deja ete confronte a toutes les alternatives que tu as cite. Et des que tu sors des sentiers battue, c'est une plaie.
Au passage, CMake générant potentiellement ( pas obligé, c'est à toi de choisir en fait ) un makefile sous linux, je ne vois pas comment il pourrait être incompatible avec les autotools, vu qu'ils intègrent GNU make.
Euh, tu melanges tout la. GNU Make ne fait pas partie des autotools. Automake, lui oui. Tous les systemes de configuration genere des Makefile et encore heureux, on peut utiliser GNU Make (entre autre) avec. Mais ce qui est important c'est ce qu'il y a dans les dits Makefile et les situations que ces outils sont capables de detecter. Donc CMake et les autotools font exactement le meme boulot, mais de maniere differente.
Après, un système comme les autotools qui ne marche que mal ( me semble qu'il marche malgré tout un peu donc… ) sur l'un des systèmes les plus populaires ( windows ), ça ne me semble pas "sérieux" comme tu dis.
J'utilise les autotools avec Windows de maniere tres reguliere en cross compilation, nativement et avec un systeme de packaging. Je dois avoir un probleme d'installation de mon systeme, si c'est cense ne pas marcher. Va encore falloir reinstaller windows /o\.
Bah, avec systemd mon window manager aura une backtrace genere et directement archive que je pourrais facilement retrouve. Il aura un watchdog qui verifiera que celui-ci est bien toujours actif (protection contre les boucles infinis). Et je peux mettre un certain nombre d'autre restriction.
Enfin, systemd va pouvoir se charger du demarrage de toutes les petites applications au demarrage de ton window manager sans que celui-ci ai a s'en occuper et en offrant les meme options que precedement. En terme de stabilite et gestion des erreurs, c'est bien plus avance que tout ce qui est implemente dans les DE actuel.
Bon, c'est pas non plus completement tout rose bonbon. KDE et Enlightenment ont tous les deux une infrastructure qui permet de precharger/prelinker/preinitialiser leur bibliotheque interne avant de demarrer une application. Hors cela repose sur fork, sans exec. Et c'est pour l'instant pas possible a implementer dans systemd, donc on perd une optimisation (Amelioration du temps de demarrage et diminution du la memoire utilise). De plus comme GNOME n'a pas ce mecanisme, et que les communautes de KDE et E ne sont pas tres engage dans le developpement de systemd, et bien je doute que l'on verra une solution a ce probleme apparaitre.
Hmm hmm, bien sûr que c'est possible. Tu peux mmaper des buffers graphiques et y acceder depuis le CPU. Inversement, les GPUs font du DMA depuis la VM de la tâche utilisateur.
Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Tu pourrais refaire des tests sur ton ordi ?
Je referais le test dimanche, mais tu as teste avec quoi ? Perso mon test, c'est de lancer emacs dans Terminology sous Enlightenment et avoir un powertop dans un second tab dans Terminology pour voir la consomation. Je coupe aussi le Wifi/Bluetooth/Ethernet pour pas avoir de variation du a un quelconque traffic.
Il pourrait même faire usage des KMS planes ce qui ferait que bouger une fenêtre consommerait ~0W coté rendu.
L'utilisation des planes pourra effectivement aider enormement. Et pas uniquement lorsqu'on utilise OpenGL, car tres souvent le hardware qui gere les plans graphiques est decorele de celui qui fait l'acceleration OpenGL. Ceux-la ouvre des trucs tres interressant. Par exemple avec 5 plans graphiques pour une application full screen, tu peux parfaitement imaginer gerer une liste verticale a 60fps en software. Tu utilises 3 plans pour la liste, un pour l'overlay, un pour le background. A tout moment, tu n'affiches jamais que 2 plan pour la liste, le 3eme etant en preparation. Avec des plans de la bonne taille, tu as le temps de mettre a jour le 3eme avant que celui ne soit affiche et tu peux le faire dans un thread separe qui ne bloquera pas l'animation des autres plans en mouvement qui ne necessite pas de rendu. Ca demande beaucoup de logique dans le toolkit (identique que ce soit avec le GPU ou en soft qu'on remplisse les dit plan). C'est aussi quelque chose qui s'applique tres bien pour les navigateurs web.
Par contre Wayland n'expose pas encore un moyen pour les applications de savoir combien de plan son disponible et si c'est une bonne idee de les utiliser (Par exemple oui pour l'application qui a le focus, moins pour celle en background). Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
peut-être un mélange vectoriel et bitmap est plus adapté, et dès qu'on veut faire du vectoriel, il faut que les toolkits suivent.
Non, mais faut arreter avec le myth du vectoriel ! Aucun toolkit moderne, aucune application n'utilise un rendu "vectoriel" de nos jours. Et il y a de tres bonne raison. La premiere etant l'impossibilite pour un toolkit de garantir le resultat graphique. Ensuite le dessin vectoriel requiert beaucoup beaucoup plus de ressource CPU et GPU que du rendu bitmap. Et enfin, il reste a trouver un cas ou ca marche bien le rendu vectoriel…
Donc peut etre que RDP n'est pas parfait, mais au moins il est sur la bonne piste. On peut tres probablement faire mieux en utilisant des codecs differents pour compresser les images, mais le principe restera le meme.
Meme en utilisant LibreOffice ? Je croyais que c'etait ce qui se faisait de mieux sous Linux pour le Firewall…
Pour le probleme de la base de registre, il y a deux options, GNOME OS ou convaincre chaque projet de migrer vers une base de registre. Une recommendation ? Me semble que tout faire facon GNOME est une meilleur strategie, suffit d'enlever des options et mettre une base de registre.
Il n'y a pas deja une base de registre dans GNOME ? Et avec mono, je pense qu'on a tout ce qu'il faut pour concurrencer Windows maintenant. Tu vois d'autre truc qui manque apres ca qu'on s'y attaque !
Exactement. Sachant qu'un gestionnaire de fenêtre est actif h24 et que 70% du parc informatique est mobile (smartphone+tablettes+notebook), le fait de solliciter le composant le plus juste (performance/consommation) pour réaliser une opération est essentiel. On a longtemps utilisé le cpu pour faire tout sauf ce pour quoi il a été conçu : du calcul séquentiel.
Si la vie etait si simple :-) Le CPU est plus efficace que le GPU quand tu dois mettre a jour qu'une petite partie de l'ecran (genre curseur qui clignote). Cas d'utilisation le plus courant. Il n'y a que quand une surface tres importante de l'ecran devient anime, que le GPU devient plus efficace (cout des transferts de donnees et des calculs supplementaires necessaires compense par la puissance brute necessaire a accomplir l'ensemble de la tache). Resultat, tu as envie d'avoir un rendu CPU la majorite du temps, avec un petit boost par GPU de temps en temps.
Sauf que la vie, elle a decide de t'embeter. L'initialisation et les transferts initiaux rendent impossible le dit scenario (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait). Tu te retrouves donc a devoir faire un choix. Etre plus efficace en batterie de maniere general et avoir une interface qui lag un peu de temps en temps, ou utiliser plus de batterie et ne pas avoir de lag. Il est donc impossible de solliciter automatiquement le composant le plus juste.
L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.
pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
Sauf que pas de bol, mais X ne peut pas gerer les ecrans individuellements et faire un rendu direct (en evitant une copie) dans ce scenario la. Avec Wayland, si les deux surfaces matchs, il est possible d'avoir un chemin raccourci et de pouvoir utiliser directement le buffer de l'application pour la sortie lie a l'ecran en question.
plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
Ca par contre, c'est un peu faux. Il y a beaucoup plus de boulot dans une implementation de Wayland que dans une implementation de X. Simplement parce que le windows manager, le composite manager et X ont ete merge ensemble.
portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer. Ce qui veut dire qu'il faut se taper la dite manipulation par cible potentiel (Et le projet Wayland n'est pour l'instant pas interresse par une telle bibliotheque). Et oui la gestion des buffers video sous Linux, Android, RPi, … est differente. Donc la portabilite est aussi complique que celle de X, sauf qu'il faut penser a porter CHAQUE implementation de Wayland completement…
de la diversité … kfreebsd …
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
avec un peu de bol, moins pénible a configurer que Xorg?
Ca, ca dependra de chaque implementation. Avec un peu de chance, sous GNOME, ils n'auront meme pas mis d'option de configuration :-D
De tout ce que tu as cite, le seul que je ne connais, c'est bjam. Mais globalement aucun ne tiens la route des que tu veux gerer un peu des configurations exotiques. La portabilite, ce n'est pas leur truc. Dans le meilleur des cas, tu as Linux (mais pas la cross compilation), Windows, Mac OS, Android et iOS. Mais ca c'est quand tu ne fais pas trop de truc complexe, genre detection de dependences optionnelles en cross compilation et quelques plateformes funny et tu haieras toutes tes dependences qui n'utilises pas les autotools.
C'est sur que si ta spec, c'est etre facile a ecrire et fonctionner sur les systemes les plus classiques. Tu as un paquet de possibilite. Mais des que ca devient serieux, il en reste que un.
Alors juste a titre d'exemple, pour un client mail, meme si tu veux juste faire une nouvelle interface, tu as bien besoin de gnutls ou openssl, une lib pour faire du pop, smtp, imap, de gpg and so on. Ceux sont des bibliotheques qui ont mis du temps a etre developper et a supporter tous les corner case du protocol. Resultat pour trouver un client mail digne de ce nom sur Android, ca a pris des annees et encore, je ne suis toujours pas satisfait…
C'est juste un exemple, mais ca marche tout aussi bien avec l'instant message, la VoIP, IRC, un editeur de texte, un viewer de PDF, … Au lieu de se concentrer juste sur l'interface, il faut se taper toute la stack qui est en dessous ! Cela se ressent sur la qualite de l'interface au final.
Ceux a base d'ObjectifC ont l'air de s'en sortir pas trop mal. Avec une appreciation personnelle, je trouve que les applications sont d'ailleurs mieux finis sur leur plateforme native que celle en Java. Mais bon, c'est probablement une question de gout.
Et je vois mal comment "90% proprio" est pire que "proprio" (tu as dit : "C'est le pire du proprietaire a mon sens. "), c'est quand même gros ta phrase.
Je n'ai aucun soucis a me repeter sur le sujet. Je considere que relayer le message Android est libre, alors que Google referme de plus en plus son etaux (controle du developpement de la plateforme, politique isolationniste du developpement, proprietarisation des nouvelles API) est pire qu'une solution qui s'annonce proprietaire d'emble, mais qui utilise des morceaux libres. Cela utilise le relais et l'amplification de la communaute en general pour relayer un message faux, car sans la partie proprietaire, tu ne peux pas faire un terminal Android.
Mais Android au sens entendu par la majorite de ses utilisateurs n'est pas libre. Ce n'est pas parce que tu as une partie qui l'est que l'ensemble l'est. Et Google joue definitivement sur la confusion que cela entraine pour continuer a assoir son expansion. C'est en cela qu'il est pire, dans ce message qu'il vehicule !
Sur ma tablette par exemple j'ai VLC, Firefox et un poc d'OpenOffice en natif. Et pour Firefox ils dessinent l'interface en Java pendant que le gros morceau en C++ se lance.
Et c'est bien le probleme. Il faut etre un gros projet pour avoir le temps et les ressources de porter un logiciel existant sur leur plateforme. L'effort a consentir est important et limite donc le developpement sur d'autres domaines qui auraient ete plus utile. Si tu discutes avec les personnes qui bossent sur le sujet (en tout cas pour ceux de VLC et OpenOffice), je suis certain qu'ils te diront que c'est plus complique cela ne devrait l'etre.
Une veritable catastrophe en terme de reutilisabilite.
Faut croire que pour que ça marche, il faut faire des catastrophes (Windows, Android…)
Tu peux tout a fait faire le rapprochement entre Android et Windows. Sauf que Android c'est activement contre la portabilite a ce niveau. Il y a bien une raison pour que les applications bien finis soit sur iOS. Avoir un environnement qui autorise la reutilisabilite, ca aide.
Si il suffit d'avoir plein d'utilisateurs, alors c'est sur Windows et Android sont parfait. Il est certain que le choix des masses a toujours ete dicte par des criteres techniques…
Et non, je ne considere pas qu'il y ait une quelconque solution qui soit techniquement parfaite. Mais en l'espece, le probleme que je pointes, est le comportement isolationniste de Google qui tend a refermer son systeme en controlant les developpeurs et les utilisateurs sous un faux air de logiciel libre. Si tu trouves cela parfait, tant mieux pour toi…
C'est quoi un "vrai" logiciel libre? Android respect-t-il les 4 libertés, oui ou non? Si oui, il est libre, point. Aucun "faux air" avec des critères qui n'ont rien à voir avec le libre (qui te sont personnels).
Euh, je ne sais pas si tu as remarque, mais la tendance est a mettre les nouvelles API dans la partie proprietaire de Android et de laisser mourrir la partie libre. Il y avait un excellent article sur le sujet, je crois chez Arstechnica. Je crois que tu fais parti de ceux qui ceux sont fait avoir…
Ya des fois où il faut arriver a se débarrasser de ce genre de choses complètement horrible.
Et ils l'ont remplace par quoi ? Rien ! Super tu te retrouves a devoir maintenir un systeme de build specifiquement pour Android. Tres tres grande avance. Heureusement que Collabora a developper quelques outils pour ameliorer la situation, mais c'est franchement une plaie.
Tu rigoles, j'esperes ! Si tu as jamais tente de developper en natif sur Android, tu as du sentir l'envie de tuer monter en toi. Ca en est au point, ou meme developper pour Windows est plus agreable ! Meme les autotools ne passent pas d'embler sur cette cible… Une veritable catastrophe en terme de reutilisabilite. On perd un temps fou a porter des choses qui marchent deja, juste parce que Google se croit seul au monde et ignore ce qui existe (Pour ne pas etre plus grossier…). Ils sont la seule alternative a Apple et donc en on profiter pour creer un ilot bien isole du reste du monde.
C'est tout a leur avantage sur le long terme, car cela veut dire qu'un nouvel entrant ne peut pas concurrencer Android en se basant juste sur GNU/Linux. C'est le pire du proprietaire a mon sens. Un faux air de logiciel libre pour appater le chalant avec une belle cage qui enferme l'utilisateur et le developpeur. Joli coup ! Chapeau bas a Google ! Meme Microsoft n'avait pas reussi un tel coup…
Si quand meme, une grande partie des scripts d'init sysv sont utilise par Ubuntu pour des petites applications comme Apache, MySQL… Donc il y a de grande chance que ceci passe a terme en systemd ceux qui faira du boulot en plus pour Ubuntu.
C'est juste une question de temps, mais Ubuntu construit sa propre ile isole du reste du monde Linux. Ils pensent pouvoir en tirer un avantage competitif, mais le resultat c'est qu'on aura de plus en plus de probleme avec Ubuntu et le reste du monde Linux. En esperant que ca ne tourne pas au drame qu'est Android !
Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ?
J'ai déjà mis ce lien dans mon post précédent plus haut.
Je ne comprend pas les bases logique de ce site et j'ai du mal a accepter certaine chose. Ainsi l'hafnium est lie dans les mines au Zirconium, donc il me parait logique que tant qu'on mine du Zirconium, on mine en meme temps de l'hafnium. D'ou le fait que je sois sceptique quand au contenu de ce site web et d'ou le fait que je demande des informations plus detailles. En general sur ce genre de sujet assez capitale de probleme d'approvisionnement en ressource, tu as toujours un papier de la CIA, de scientifique ou d'un think tank qui explique en long et en large le probleme.
que ça passe à l'échelle sur le volume (c'est toute la différence entre le lab et l'échelle industrielle !)
Tout depend de ce que l'on cherche, mais certains asteroid contienne a eux seul plus par exemple de platine que ce que l'humanite a exploiter depuis qu'on exploite le platine. Les volumes ne sont clairement pas le probleme ici.
que ça passe à l'échelle dans la durée (ben oui, tes objets celestes se baladent dans l'espace et ne vont pas rester bien sagement à proximité de notre bonne vieille terre. Accessoirement, on ne sait déjà pas nettoyer la poubelle spatiale qu'on est en train de créer…)
Euh, tu te contredis un peu. D'un cote tu dis que les objets celetes se baladent et de l'autre qu'il reste trop a proximite de la terre :-) Plus serieusement, la mecanique et la navigation spatiale, au vu des prouesses realises par nos sondes est quelques chose de bien maitrise… Une fois qu'on saura comment "pousser" un asteroid !
que tu ne consommes pas de ressources pour l'ensemble de l'activité "minière" elle-même (regarde combien d'énergie il faut pour satelliser 1kg…). C'est précisément un élément limitant pour le passage à l'échelle sur le volume.
C'est effectivement un des challenge, mais je n'aurais pas mis celui la en premier. Il faut les cartographiers, reussir a "atterir" dessus, les decouper en petit morceaux et les traiter avant de les renvoyer la ou on en a besoin. Clairement des tres gros problemes d'ingenierie et il faut probablement compter en decennie avant de resoudre ces problemes. Mais le probleme des volumes n'est probablement pas le premier sur la liste.
le thorium lui-même est abondant, mais quid des autres éléments rares qui seront nécessaires pour que l'ensemble de l'édifice fonctionne ? (par exemple, les barres de MOX des centrales actuelles sont entourées de gaines de zirconium, dont les réserves au rythme actuel sont d'environ 40 ans)
Avec ce genre de question on ne va rien faire. Oui, toutes les ressources que l'on exploite, sont fini, s'epuiseront un jour et pour beaucoup d'entre elle dans un futur assez proche. De maniere corolaire, il n'y a aucune source d'energie qui ne consomme pas de ces matieres qui se rarefie pour etre produite. Soit on arrete tout pour ne pas les epuiser soit on avance. La veritable question etant plutot ou est-ce que l'on doit diriger ces ressources ? Dans des telephones et tablettes ou dans la technologie spatiale et l'energie ? Et non, la chasse au gaspi n'est qu'une solution temporaire qui repousse l'inevitable.
1/ Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ? Parce que au meme titre, tous les puits de shale gaz actuellement en exploitation seront aussi vide en 2018 (Du fait de leur duree de vie d'environ 5 ans).
2,3/ Toute exploitation de ressource suit une courbe qui passe par un maximum et decroit. Partant de la, tu peux considerer la terre comme une unique mine et donc il y a forcement un maximum et apres ce sera la decroissance. C'est une evidence et elle est indiscutable. Tout aussi indiscutable est le fait que la majorite des metaux que l'on utilise ne tiendront pour la plus part pas plus de 30 ans de production au rythme actuel. Et a part stopper toute activite, il n'y a aucun moyen d'empecher ces predictions de devenir des faits. Il devient donc logique de commencer a investir maintenant dans les technologies d'exploitation spatiale de ressource.
4/ De ce que j'ai compris de la question, cela semble etre plus une question d'ingenierie que de recherche fondamentale. C'est a dire que les ressources etant la, il n'y a rien qui semble bloquant pour arriver a un resultat, contrairement a d'autre technologie, tel que la fusion, qui ont plus de probleme theorique a resoudre.
Si c'est une terre rare, alors c'est un faux probleme. La raison de la rarete des dites terre rare et de leur production d'origine Chinoise, c'est qu'elles sont massivement melange a des gisements de Thorium, materiaux radioactif. Hors dans les pays occidentaux, l'exploitation de gisement radioactif est tres reglemente et surveille. De plus le Thorium est actuellement inutilisable pour toutes les centrales de la planete, ce qui en fait un dechet radioactif des le depart. Ceux la rend l'exploitation complique de ce genre de mine.
Mais ce que font les Chinois, c'est juste de constituer des stocks de Thorium et lancer en parallele la R&D necessaire a la production nucleaire en utilisant comme carburant le Thorium… Ils sont d'ailleur les plus gros investisseurs dans le domaine, ce qui perenisera leur production de terre rare. Et d'ou ma remarque que la depletion des reserves de terre rare, n'est qu'un probleme d'ingenierie.
Mais personne ne pense à corriger le code. Non, il vaut mieux nous fourguer un autre machin qu'il faudra à son tour corriger parce qu'il se révélera lui aussi au final un pure passoire, mais sinon, c'est pas grave.
Vu ton niveau d'information technique, je vais partir de l'image que tu as choisi. X11, c'est une passoir au niveau meme du protocol. Il n'y a pas de securite, des que tu lances une application, c'est game over. Et c'est impossible de "corriger" le probleme sans casser le protocol (Les emulateurs, les logiciels de capture d'ecran, LibreOffice, … ne marcheraient plus du tout en rendant le protocol "securise"). En gros, c'est comme ci, tu disais qu'il suffirait de reboucher tous les trous de la passoire pour avoir une meilleur solution et que la moitie de la planete utilise la dite passoir pour essorer les nouilles. Autant dire que d'un point de vue fonctionnel, tes pates risques de rester assez humide et peu mangeable pour une bonne partie de la planete apres avoir corriger le probleme (Ils pourront se mettre a la soupe de nouille certe). C'est juste techniquement impossible de securiser le protocol sans casser un tres grand nombre d'application et la je n'ai pris que un seul exemple du protocol.
Pour moi les systèmes Posix sont sensés contrairement à "fenêtre" s'adapter à l'utilisateur et pas le contraire, mais dans la réalité, on voit plus des développeurs qui se flattent l'ego plutôt que de penser à fournir un système véritablement user friendly qui s'adapte aux besoins des utilisateurs sans les obliger à fonctionner d'une manière plutôt que d'une autre.
Oula, tu as ete tres tres mal informe ! Le monde du logiciel libre deja n'a rien a voir avec Posix qui est un standard qui s'arrete assez bas dans les couches logiciels. Et pour ce qui nous concerne ici, qui n'a rien a voir avec Posix et tout a voir avec le logiciel libre, tu es libre de contribue, mais si tu ne le fais pas, venir te plaindre ne sert a rien. Le logiciel libre n'a d'objectif que de satisfaire ceux qui le code. Si ca leur fait plaisir de satisfaire des energumenes retrograde qui gueulent sans rien comprendre, et bien tu as de la chance, sinon tant pis pour toi.
Si tu sous entend qu'ils auraient du passer directement a qml, je pense que ça aurait été un saut trop gros saut et pas forcément de chemin d'évolution progressif.
Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?
Je crois que tu n'as aucune idee de ce que fait la concurrence techniquement ! Un peu comme lors d'une demo, ceux qui compte, c'est les graphismes. A cour terme pour faire croire qu'on fait quelques choses de nouveau, il suffit de changer les icones, les gradients, deplacer et relooker les toolbar. Et tada, tu as des utilisateurs qui sont sur d'avoir quelques choses de neuf !
Alors que c'est le meme moteur de rendu, le meme coeur de calcul, juste plus lent que la precedente version, car la hierachie de toutes les grosses societes seraient contre la reecriture de ces morceaux critiques ! Or les avances de LibreOffice dans le domaine sont extremement prometteur bien plus que la concurrence. Faire le relooking et etre hype arrivera apres lorsque l'infrastructure sera proprement en place.
Mais c'est vrai qu'une joli demo, ca a toujours fait plus vendre meme si ca ne fait pas un produit utilisable…
[^] # Re: Mon avis personnel
Posté par cedric . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 5.
Va falloir definir de quel type d'embarque dont tu parles. Parce que il y a une raison pour que OpenEmbedded utilise systemd depuis quelques temps ! Et dans le cas de machin trop petit pour systemd, tu vas franchement pas etre loin de devoir coder ton init tout seul…
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Tout a fait.
Pour un Window Manager simple oui. Pour un compositeur, meme simple, c'est deja un peu plus gros. Mais le probleme va se poser des que tu vas vouloir supporter un peu plus que juste les machines x86 (genre un backend specifique pour RPi ou n'importe laquelle des plateforme ARM en fait). La complexite explose tres rapidement de ce cote la. Ensuite si tu veux avoir des perfs decentes, tu vas devoir aussi optimiser pas mal ton compositeur, et forcement le nombre de ligne va augmenter. Au final, il sera tres difficile de refaire des tres petits WM comme sous X (Normal vu qu'il faut implementer une bonne partie de ce qui est dans X aujourd'hui).
Principalement une volonte du mainteneur de Wayland/Weston qui ne voit pas d'utiliter a cela. Il pourrait changer d'avis un jour…
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 3.
J'ai pas du etre clair, mais j'ai deja ete confronte a toutes les alternatives que tu as cite. Et des que tu sors des sentiers battue, c'est une plaie.
Euh, tu melanges tout la. GNU Make ne fait pas partie des autotools. Automake, lui oui. Tous les systemes de configuration genere des Makefile et encore heureux, on peut utiliser GNU Make (entre autre) avec. Mais ce qui est important c'est ce qu'il y a dans les dits Makefile et les situations que ces outils sont capables de detecter. Donc CMake et les autotools font exactement le meme boulot, mais de maniere differente.
J'utilise les autotools avec Windows de maniere tres reguliere en cross compilation, nativement et avec un systeme de packaging. Je dois avoir un probleme d'installation de mon systeme, si c'est cense ne pas marcher. Va encore falloir reinstaller windows /o\.
[^] # Re: Mon avis personnel
Posté par cedric . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 5.
Bah, avec systemd mon window manager aura une backtrace genere et directement archive que je pourrais facilement retrouve. Il aura un watchdog qui verifiera que celui-ci est bien toujours actif (protection contre les boucles infinis). Et je peux mettre un certain nombre d'autre restriction.
Enfin, systemd va pouvoir se charger du demarrage de toutes les petites applications au demarrage de ton window manager sans que celui-ci ai a s'en occuper et en offrant les meme options que precedement. En terme de stabilite et gestion des erreurs, c'est bien plus avance que tout ce qui est implemente dans les DE actuel.
Bon, c'est pas non plus completement tout rose bonbon. KDE et Enlightenment ont tous les deux une infrastructure qui permet de precharger/prelinker/preinitialiser leur bibliotheque interne avant de demarrer une application. Hors cela repose sur fork, sans exec. Et c'est pour l'instant pas possible a implementer dans systemd, donc on perd une optimisation (Amelioration du temps de demarrage et diminution du la memoire utilise). De plus comme GNOME n'a pas ce mecanisme, et que les communautes de KDE et E ne sont pas tres engage dans le developpement de systemd, et bien je doute que l'on verra une solution a ce probleme apparaitre.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 3.
Si tu le fais, tu te retrouves avec un buffer cote GPU qui n'est pas dans son format interne et tu perds en performance (Cela se sent pas mal sur les GPU ARM, moins sur Intel). De plus dans toutes les implementations que j'ai vu sur ARM, celui-ci forcait un stall du pipeline cote GPU (Theoriquement non necessaire, si on a des texture double bufferises mais je n'ai jamais vu d'implementation qui faisait cela (je n'ai pas regarder ce que faisait mon intel)). Il ne faut pas oublier qu'un compositeur a la difference d'un jeu, va updater ses textures quasiment a chaque frame. Ceux sont donc des problemes que seul les compositeurs voient. Le fait est que les drivers sont pour l'instant optimise pour les jeux pleines ecran lorsque le compositeur est desactive et qu'il y a encore beaucoup de boulot de ce cote la.
Je referais le test dimanche, mais tu as teste avec quoi ? Perso mon test, c'est de lancer emacs dans Terminology sous Enlightenment et avoir un powertop dans un second tab dans Terminology pour voir la consomation. Je coupe aussi le Wifi/Bluetooth/Ethernet pour pas avoir de variation du a un quelconque traffic.
L'utilisation des planes pourra effectivement aider enormement. Et pas uniquement lorsqu'on utilise OpenGL, car tres souvent le hardware qui gere les plans graphiques est decorele de celui qui fait l'acceleration OpenGL. Ceux-la ouvre des trucs tres interressant. Par exemple avec 5 plans graphiques pour une application full screen, tu peux parfaitement imaginer gerer une liste verticale a 60fps en software. Tu utilises 3 plans pour la liste, un pour l'overlay, un pour le background. A tout moment, tu n'affiches jamais que 2 plan pour la liste, le 3eme etant en preparation. Avec des plans de la bonne taille, tu as le temps de mettre a jour le 3eme avant que celui ne soit affiche et tu peux le faire dans un thread separe qui ne bloquera pas l'animation des autres plans en mouvement qui ne necessite pas de rendu. Ca demande beaucoup de logique dans le toolkit (identique que ce soit avec le GPU ou en soft qu'on remplisse les dit plan). C'est aussi quelque chose qui s'applique tres bien pour les navigateurs web.
Par contre Wayland n'expose pas encore un moyen pour les applications de savoir combien de plan son disponible et si c'est une bonne idee de les utiliser (Par exemple oui pour l'application qui a le focus, moins pour celle en background). Clairement la standardisation de l'API pour manipuler les plans ouvrent un certain nombre de chose tres interressante cote toolkit, mais il y a du boulot !
[^] # Re: Grosse fatigue
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 5.
Non, mais faut arreter avec le myth du vectoriel ! Aucun toolkit moderne, aucune application n'utilise un rendu "vectoriel" de nos jours. Et il y a de tres bonne raison. La premiere etant l'impossibilite pour un toolkit de garantir le resultat graphique. Ensuite le dessin vectoriel requiert beaucoup beaucoup plus de ressource CPU et GPU que du rendu bitmap. Et enfin, il reste a trouver un cas ou ca marche bien le rendu vectoriel…
Donc peut etre que RDP n'est pas parfait, mais au moins il est sur la bonne piste. On peut tres probablement faire mieux en utilisant des codecs differents pour compresser les images, mais le principe restera le meme.
[^] # Re: Perso...
Posté par cedric . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 3.
Meme en utilisant LibreOffice ? Je croyais que c'etait ce qui se faisait de mieux sous Linux pour le Firewall…
Pour le probleme de la base de registre, il y a deux options, GNOME OS ou convaincre chaque projet de migrer vers une base de registre. Une recommendation ? Me semble que tout faire facon GNOME est une meilleur strategie, suffit d'enlever des options et mettre une base de registre.
[^] # Re: Perso...
Posté par cedric . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 4.
Il n'y a pas deja une base de registre dans GNOME ? Et avec mono, je pense qu'on a tout ce qu'il faut pour concurrencer Windows maintenant. Tu vois d'autre truc qui manque apres ca qu'on s'y attaque !
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Si la vie etait si simple :-) Le CPU est plus efficace que le GPU quand tu dois mettre a jour qu'une petite partie de l'ecran (genre curseur qui clignote). Cas d'utilisation le plus courant. Il n'y a que quand une surface tres importante de l'ecran devient anime, que le GPU devient plus efficace (cout des transferts de donnees et des calculs supplementaires necessaires compense par la puissance brute necessaire a accomplir l'ensemble de la tache). Resultat, tu as envie d'avoir un rendu CPU la majorite du temps, avec un petit boost par GPU de temps en temps.
Sauf que la vie, elle a decide de t'embeter. L'initialisation et les transferts initiaux rendent impossible le dit scenario (Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait). Tu te retrouves donc a devoir faire un choix. Etre plus efficace en batterie de maniere general et avoir une interface qui lag un peu de temps en temps, ou utiliser plus de batterie et ne pas avoir de lag. Il est donc impossible de solliciter automatiquement le composant le plus juste.
L'approche d'Android qui propose un mode basse consomation, consiste exactement en cela. L'utilisateur choisit alors le rendu CPU qui statistiquement est plus efficace que le rendu GPU.
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Sauf que pas de bol, mais X ne peut pas gerer les ecrans individuellements et faire un rendu direct (en evitant une copie) dans ce scenario la. Avec Wayland, si les deux surfaces matchs, il est possible d'avoir un chemin raccourci et de pouvoir utiliser directement le buffer de l'application pour la sortie lie a l'ecran en question.
Ca par contre, c'est un peu faux. Il y a beaucoup plus de boulot dans une implementation de Wayland que dans une implementation de X. Simplement parce que le windows manager, le composite manager et X ont ete merge ensemble.
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer. Ce qui veut dire qu'il faut se taper la dite manipulation par cible potentiel (Et le projet Wayland n'est pour l'instant pas interresse par une telle bibliotheque). Et oui la gestion des buffers video sous Linux, Android, RPi, … est differente. Donc la portabilite est aussi complique que celle de X, sauf qu'il faut penser a porter CHAQUE implementation de Wayland completement…
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
Ca, ca dependra de chaque implementation. Avec un peu de chance, sous GNOME, ils n'auront meme pas mis d'option de configuration :-D
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
De tout ce que tu as cite, le seul que je ne connais, c'est bjam. Mais globalement aucun ne tiens la route des que tu veux gerer un peu des configurations exotiques. La portabilite, ce n'est pas leur truc. Dans le meilleur des cas, tu as Linux (mais pas la cross compilation), Windows, Mac OS, Android et iOS. Mais ca c'est quand tu ne fais pas trop de truc complexe, genre detection de dependences optionnelles en cross compilation et quelques plateformes funny et tu haieras toutes tes dependences qui n'utilises pas les autotools.
C'est sur que si ta spec, c'est etre facile a ecrire et fonctionner sur les systemes les plus classiques. Tu as un paquet de possibilite. Mais des que ca devient serieux, il en reste que un.
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 8.
Alors juste a titre d'exemple, pour un client mail, meme si tu veux juste faire une nouvelle interface, tu as bien besoin de gnutls ou openssl, une lib pour faire du pop, smtp, imap, de gpg and so on. Ceux sont des bibliotheques qui ont mis du temps a etre developper et a supporter tous les corner case du protocol. Resultat pour trouver un client mail digne de ce nom sur Android, ca a pris des annees et encore, je ne suis toujours pas satisfait…
C'est juste un exemple, mais ca marche tout aussi bien avec l'instant message, la VoIP, IRC, un editeur de texte, un viewer de PDF, … Au lieu de se concentrer juste sur l'interface, il faut se taper toute la stack qui est en dessous ! Cela se ressent sur la qualite de l'interface au final.
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Ceux a base d'ObjectifC ont l'air de s'en sortir pas trop mal. Avec une appreciation personnelle, je trouve que les applications sont d'ailleurs mieux finis sur leur plateforme native que celle en Java. Mais bon, c'est probablement une question de gout.
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Je n'ai aucun soucis a me repeter sur le sujet. Je considere que relayer le message Android est libre, alors que Google referme de plus en plus son etaux (controle du developpement de la plateforme, politique isolationniste du developpement, proprietarisation des nouvelles API) est pire qu'une solution qui s'annonce proprietaire d'emble, mais qui utilise des morceaux libres. Cela utilise le relais et l'amplification de la communaute en general pour relayer un message faux, car sans la partie proprietaire, tu ne peux pas faire un terminal Android.
Mais Android au sens entendu par la majorite de ses utilisateurs n'est pas libre. Ce n'est pas parce que tu as une partie qui l'est que l'ensemble l'est. Et Google joue definitivement sur la confusion que cela entraine pour continuer a assoir son expansion. C'est en cela qu'il est pire, dans ce message qu'il vehicule !
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 2.
Et c'est bien le probleme. Il faut etre un gros projet pour avoir le temps et les ressources de porter un logiciel existant sur leur plateforme. L'effort a consentir est important et limite donc le developpement sur d'autres domaines qui auraient ete plus utile. Si tu discutes avec les personnes qui bossent sur le sujet (en tout cas pour ceux de VLC et OpenOffice), je suis certain qu'ils te diront que c'est plus complique cela ne devrait l'etre.
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Tu peux tout a fait faire le rapprochement entre Android et Windows. Sauf que Android c'est activement contre la portabilite a ce niveau. Il y a bien une raison pour que les applications bien finis soit sur iOS. Avoir un environnement qui autorise la reutilisabilite, ca aide.
Si il suffit d'avoir plein d'utilisateurs, alors c'est sur Windows et Android sont parfait. Il est certain que le choix des masses a toujours ete dicte par des criteres techniques…
Et non, je ne considere pas qu'il y ait une quelconque solution qui soit techniquement parfaite. Mais en l'espece, le probleme que je pointes, est le comportement isolationniste de Google qui tend a refermer son systeme en controlant les developpeurs et les utilisateurs sous un faux air de logiciel libre. Si tu trouves cela parfait, tant mieux pour toi…
Euh, je ne sais pas si tu as remarque, mais la tendance est a mettre les nouvelles API dans la partie proprietaire de Android et de laisser mourrir la partie libre. Il y avait un excellent article sur le sujet, je crois chez Arstechnica. Je crois que tu fais parti de ceux qui ceux sont fait avoir…
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Et ils l'ont remplace par quoi ? Rien ! Super tu te retrouves a devoir maintenir un systeme de build specifiquement pour Android. Tres tres grande avance. Heureusement que Collabora a developper quelques outils pour ameliorer la situation, mais c'est franchement une plaie.
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 9.
Tu rigoles, j'esperes ! Si tu as jamais tente de developper en natif sur Android, tu as du sentir l'envie de tuer monter en toi. Ca en est au point, ou meme developper pour Windows est plus agreable ! Meme les autotools ne passent pas d'embler sur cette cible… Une veritable catastrophe en terme de reutilisabilite. On perd un temps fou a porter des choses qui marchent deja, juste parce que Google se croit seul au monde et ignore ce qui existe (Pour ne pas etre plus grossier…). Ils sont la seule alternative a Apple et donc en on profiter pour creer un ilot bien isole du reste du monde.
C'est tout a leur avantage sur le long terme, car cela veut dire qu'un nouvel entrant ne peut pas concurrencer Android en se basant juste sur GNU/Linux. C'est le pire du proprietaire a mon sens. Un faux air de logiciel libre pour appater le chalant avec une belle cage qui enferme l'utilisateur et le developpeur. Joli coup ! Chapeau bas a Google ! Meme Microsoft n'avait pas reussi un tel coup…
[^] # Re: En fait la discussion continue
Posté par cedric . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Si quand meme, une grande partie des scripts d'init sysv sont utilise par Ubuntu pour des petites applications comme Apache, MySQL… Donc il y a de grande chance que ceci passe a terme en systemd ceux qui faira du boulot en plus pour Ubuntu.
C'est juste une question de temps, mais Ubuntu construit sa propre ile isole du reste du monde Linux. Ils pensent pouvoir en tirer un avantage competitif, mais le resultat c'est qu'on aura de plus en plus de probleme avec Ubuntu et le reste du monde Linux. En esperant que ca ne tourne pas au drame qu'est Android !
[^] # Re: OpenGL ES et Sandy Bridge
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Je ne comprend pas les bases logique de ce site et j'ai du mal a accepter certaine chose. Ainsi l'hafnium est lie dans les mines au Zirconium, donc il me parait logique que tant qu'on mine du Zirconium, on mine en meme temps de l'hafnium. D'ou le fait que je sois sceptique quand au contenu de ce site web et d'ou le fait que je demande des informations plus detailles. En general sur ce genre de sujet assez capitale de probleme d'approvisionnement en ressource, tu as toujours un papier de la CIA, de scientifique ou d'un think tank qui explique en long et en large le probleme.
Tout depend de ce que l'on cherche, mais certains asteroid contienne a eux seul plus par exemple de platine que ce que l'humanite a exploiter depuis qu'on exploite le platine. Les volumes ne sont clairement pas le probleme ici.
Euh, tu te contredis un peu. D'un cote tu dis que les objets celetes se baladent et de l'autre qu'il reste trop a proximite de la terre :-) Plus serieusement, la mecanique et la navigation spatiale, au vu des prouesses realises par nos sondes est quelques chose de bien maitrise… Une fois qu'on saura comment "pousser" un asteroid !
C'est effectivement un des challenge, mais je n'aurais pas mis celui la en premier. Il faut les cartographiers, reussir a "atterir" dessus, les decouper en petit morceaux et les traiter avant de les renvoyer la ou on en a besoin. Clairement des tres gros problemes d'ingenierie et il faut probablement compter en decennie avant de resoudre ces problemes. Mais le probleme des volumes n'est probablement pas le premier sur la liste.
Avec ce genre de question on ne va rien faire. Oui, toutes les ressources que l'on exploite, sont fini, s'epuiseront un jour et pour beaucoup d'entre elle dans un futur assez proche. De maniere corolaire, il n'y a aucune source d'energie qui ne consomme pas de ces matieres qui se rarefie pour etre produite. Soit on arrete tout pour ne pas les epuiser soit on avance. La veritable question etant plutot ou est-ce que l'on doit diriger ces ressources ? Dans des telephones et tablettes ou dans la technologie spatiale et l'energie ? Et non, la chasse au gaspi n'est qu'une solution temporaire qui repousse l'inevitable.
[^] # Re: OpenGL ES et Sandy Bridge
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
1/ Je n'ai pas trouve d'info sur le sujet, tu aurais un lien ? Parce que au meme titre, tous les puits de shale gaz actuellement en exploitation seront aussi vide en 2018 (Du fait de leur duree de vie d'environ 5 ans).
2,3/ Toute exploitation de ressource suit une courbe qui passe par un maximum et decroit. Partant de la, tu peux considerer la terre comme une unique mine et donc il y a forcement un maximum et apres ce sera la decroissance. C'est une evidence et elle est indiscutable. Tout aussi indiscutable est le fait que la majorite des metaux que l'on utilise ne tiendront pour la plus part pas plus de 30 ans de production au rythme actuel. Et a part stopper toute activite, il n'y a aucun moyen d'empecher ces predictions de devenir des faits. Il devient donc logique de commencer a investir maintenant dans les technologies d'exploitation spatiale de ressource.
4/ De ce que j'ai compris de la question, cela semble etre plus une question d'ingenierie que de recherche fondamentale. C'est a dire que les ressources etant la, il n'y a rien qui semble bloquant pour arriver a un resultat, contrairement a d'autre technologie, tel que la fusion, qui ont plus de probleme theorique a resoudre.
[^] # Re: OpenGL ES et Sandy Bridge
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Si c'est une terre rare, alors c'est un faux probleme. La raison de la rarete des dites terre rare et de leur production d'origine Chinoise, c'est qu'elles sont massivement melange a des gisements de Thorium, materiaux radioactif. Hors dans les pays occidentaux, l'exploitation de gisement radioactif est tres reglemente et surveille. De plus le Thorium est actuellement inutilisable pour toutes les centrales de la planete, ce qui en fait un dechet radioactif des le depart. Ceux la rend l'exploitation complique de ce genre de mine.
Mais ce que font les Chinois, c'est juste de constituer des stocks de Thorium et lancer en parallele la R&D necessaire a la production nucleaire en utilisant comme carburant le Thorium… Ils sont d'ailleur les plus gros investisseurs dans le domaine, ce qui perenisera leur production de terre rare. Et d'ou ma remarque que la depletion des reserves de terre rare, n'est qu'un probleme d'ingenierie.
[^] # Re: Grosse fatigue
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 10.
Vu ton niveau d'information technique, je vais partir de l'image que tu as choisi. X11, c'est une passoir au niveau meme du protocol. Il n'y a pas de securite, des que tu lances une application, c'est game over. Et c'est impossible de "corriger" le probleme sans casser le protocol (Les emulateurs, les logiciels de capture d'ecran, LibreOffice, … ne marcheraient plus du tout en rendant le protocol "securise"). En gros, c'est comme ci, tu disais qu'il suffirait de reboucher tous les trous de la passoire pour avoir une meilleur solution et que la moitie de la planete utilise la dite passoir pour essorer les nouilles. Autant dire que d'un point de vue fonctionnel, tes pates risques de rester assez humide et peu mangeable pour une bonne partie de la planete apres avoir corriger le probleme (Ils pourront se mettre a la soupe de nouille certe). C'est juste techniquement impossible de securiser le protocol sans casser un tres grand nombre d'application et la je n'ai pris que un seul exemple du protocol.
Oula, tu as ete tres tres mal informe ! Le monde du logiciel libre deja n'a rien a voir avec Posix qui est un standard qui s'arrete assez bas dans les couches logiciels. Et pour ce qui nous concerne ici, qui n'a rien a voir avec Posix et tout a voir avec le logiciel libre, tu es libre de contribue, mais si tu ne le fais pas, venir te plaindre ne sert a rien. Le logiciel libre n'a d'objectif que de satisfaire ceux qui le code. Si ca leur fait plaisir de satisfaire des energumenes retrograde qui gueulent sans rien comprendre, et bien tu as de la chance, sinon tant pis pour toi.
[^] # Re: Mouahis
Posté par cedric . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 2.
Si tu sous entend qu'ils auraient du passer directement a qml, je pense que ça aurait été un saut trop gros saut et pas forcément de chemin d'évolution progressif.
[^] # Re: Mouahis
Posté par cedric . En réponse à la dépêche LibreOffice 4.2.0 est disponible. Évalué à 2.
Je crois que tu n'as aucune idee de ce que fait la concurrence techniquement ! Un peu comme lors d'une demo, ceux qui compte, c'est les graphismes. A cour terme pour faire croire qu'on fait quelques choses de nouveau, il suffit de changer les icones, les gradients, deplacer et relooker les toolbar. Et tada, tu as des utilisateurs qui sont sur d'avoir quelques choses de neuf !
Alors que c'est le meme moteur de rendu, le meme coeur de calcul, juste plus lent que la precedente version, car la hierachie de toutes les grosses societes seraient contre la reecriture de ces morceaux critiques ! Or les avances de LibreOffice dans le domaine sont extremement prometteur bien plus que la concurrence. Faire le relooking et etre hype arrivera apres lorsque l'infrastructure sera proprement en place.
Mais c'est vrai qu'une joli demo, ca a toujours fait plus vendre meme si ca ne fait pas un produit utilisable…