dave_null a écrit 358 commentaires

Oui, les développeurs de Mir se sont ridiculisés, ça ne veut pas dire qu'ils soient incompétents, juste qu'ils n'ont pas les compétences et l'expérience pour développer un serveur d'affichage.

Et bien ils apprendront.

Pour les développeurs de Wayland, je comprends que lire des choses fausses sur leur projet doit les énerver. Mais j'ai l'impression qu'ils se considèrent comme une élite et qu'il faut des compétences exceptionnelles pour arriver à leur niveau.

Quelque part, ce n'est qu'un serveur d'affichage, c'est compliqué et technique mais pas un développement impossible. Je ne doute pas que les ingénieurs de Cannonical peuvent apprendre et faire un travail de qualité, même en partant de zéro.

C'est sobre, c'est beau, c'est efficace.

Après je n'ai que testé quelques heures, mais le principal reproche que j'ai est la confrontation entre le mode métro et le mode classique. Je pense qu'ils sont conscient de ce problème et que le prochain windows sera bien meilleur sur cet aspect.

Personnellement j'aime beaucoup l'interface de windows 8 et son esthétisme.

Après j'ai mis 5 minutes à trouver comment éteindre le pc (souris en bas à droite de l'écran, paramètre, arrêter), c'est plus con que «Démarre -> Arrêter» mais c'est plus accessible qu'à une époque sur Gnome3…

Si metro était libre et tournait sur GNU/Linux, je pense que j'utiliserais Métro.

Je critique les strategies multitache, car elles ont un impact sur l'utilisabilite du systeme et qu'elles ne sont pas necessaire.
Elles permettent d'avoir une bonne autonomie sur des machines performantes et avec des petites batteries.

Je peux faire tourner un desktop avec 256Mo de RAM sans probleme. Pourquoi donc ce n'est pas possible sous Android ? Et probablement aussi avec Firefox Os. La reponse est simple. Chaque VM est completement isole, il y a peu de partage de donnees entre les process. Le toolkit ne favorise pas l'optimisation de la consommation memoire pour faire simple.
On est d'accord, mais ce n'est pas vraiment grave selon moi.

Qu'est-ce qu'on peut faire sous Linux de mieux, partage des ressources graphiques (image et font) entre tous les process par exemple. Ca permet entre autre de demarrer les applications plus rapidement, car les images sont deja charge en memoire. Avec Wayland on pourra meme directement s'organiser pour partager les buffers memoire et donc eviter de reuploader les pixels en double dans la carte graphique.
Ça ressemble à des optimisations de bous de chandelle qui n'ont aucun sens. Trouve moi une seule utilisation qui justifie le coût de développement permettant de partager des pixels entre des applications.

Ensuite quand on fait un systeme, on l'optimise pour un toolkit, celui-ci peut facilement fournir une mini application qui initialisera partiellement le toolkit et se preparera a faire juste un fork + dlopen au lieu de fork + exec. Le resultat, c'est le partage de quasiment toutes les pages memoires de tes bibliotheques plus une partie des donnees d'initialisation de ton toolkit. Ca ameliore d'autant le temps de demarrage d'une application. Il devient alors possible de demarrer une application meme sur un telephone bas de gamme avant que ton doigt ait quitte l'ecran.
En général on préfère lancer les actions quand le doigt quitte l'écran. Si on le fait quand le doigt touche l'écran, ça rentre en conflit avec les autres actions (glisser et agrandir par exemple) et l'utilisateur ne peut pas ajuster le positionnement de son doigt. L'utilité est donc faible, le plus simple est de mettre une transition pour faire patienter l'utilisateur durant le lancement.

La raison pour laquelle, il n'y a rien sur le mobile, c'est parce qu'il faut des moyens. Trouve moi un telephone avec une stack complete jusqu'a Wayland ou X, avec tous les drivers d'operationnels et je suis sur que en moins de 6 mois tu auras un telephone Enlightenment ou Plasma Active.
T'auras peut-être une superbe architecture pour construire une interface qui sera toujours visuellement identique, mais tu n'auras pas d'applications à mettre dessus. Et sans applications, pas de succès.

Et vu ta capacite a comprendre les contraintes techniques et les pre requis pour faire du developpement d'une interface, ca sert a rien que tu gagnes au Loto, de toute facon tu gaspilerrais l'argent.
Si je gagnais au loto, je ferais autre chose que de l'investir dans un nouvel os mobile, le marché des os alternatifs est quasiment saturé.

Maintenant nous avons deux profils différents, tu envisages de partager les buffers des images dans la carte graphique pendant que je préfère me concentrer sur les interfaces utilisateurs et les applications proposées, au détriment de la consommation mémoire. Ça serait intéressant de se donner 20 millions chacun et 2 ans, pour ensuite comparer quel produit final a le plus de succès auprès des utilisateurs.

Tu critiques le fait que la mémoire consomme beaucoup, mais tu critiques aussi les stratégies multitaches qui sont mises en place pour limiter la consommation.

Le modèle multitache d'Android n'est peut-être pas parfait mais en attendant il est facile d'avoir une autonomie qui dépasse de plusieurs fois celle d'un eeePC. Alors ça coupe les applications qui consomment en tache de fond mais il faut bien des compromis.

Pour ton client IRC, il gère peut-être mal le multitache d'Android car il est possible de laisser tourner un processus en permanence (au prix d'une icône dans la zone de notifications).

L'existence de GNU/Linux sur le desktop ou le mobile est conditionné à sa capacité à répondre aux besoins des utilisateurs. Sur le desktop, c'est plutôt très positif, mais sur le mobile il n'y a rien.

Si aujourd'hui j'ai 20 millions d'euros pour sortir un mobile, je vois pas pourquoi je m’embêterais à investir dans GNU/Linux. La majorité de ses utilisateurs n'aiment pas le mobile et il n'y a pas d'avantage technique à l'utiliser.
En fait j'investirais ces 20 millions dans Firefox OS ou un équivalent.

Je connais, j'ai fait un TD de reconnaissance de signes…

C'est une bonne lib, mais dire «petite lib», «extrêmement simple à utiliser», «2h pour comprendre», c'est un peu osé quand même. Si on se contente de compiler l'exemple de suivi des visages, effectivement c'est accessible.

Je ne sais pas où c'est que t'as vu qu'il faut préciser la liste des navigateurs et leurs versions supportés en HTML5.

Oui, mais tant qu'à faire ce genre de comparaisons, l'empreinte mémoire de ncurses me semble bien plus faible. C'est vraiment de la merde le web en fait.

Le message est faux. Il n'y a pas de différence entre Firefox Windows, Mac, ou Linux du point de vue du développeur web.

Le «write once, run on every navigator» est le plus courant. C'est ton exemple qui est l'exception.

Et il ne faut pas explicitement coder le support pour tout les navigateurs, mais ne pas coder pour un navigateur spécifique.

Et c'est même le cas pour les versions récentes d'internet explorer.

Même si ton application est développée pour un seul navigateur, elle est multi-plateformes. Internet Explorer par exemple fonctionne sur ARM (windows phone), PowerPC (Xbox360) et X86.

Si tu n'utilises pas de spécificités d'un navigateur, tu n'as pas à le supporter explicitement. Si tu veux utiliser les spécificités d'un navigateur, tu assumes comme tu ferais avec des #ifdef, mais ce n'est plus vraiment lié au travail du W3C.

Les applications web qui t'affichent ces messages ne devraient pas les afficher, mais mieux gérer leur développement pour être multi-navigateurs.

La seule chose que j'ai trouvé est ce hello-world : http://www.milk.com/kodebase/dalvik-docs-mirror/docs/hello-world.html

Ce que j'ai pu lire est que c'est à destination des terminaux mobiles sous Android même si il semblerait que ça puisse tourner sur un GNU/Linux après un effort de portage.

Vaut mieux faire du web :D

Peut-être Dalvik (http://fr.wikipedia.org/wiki/Dalvik_(machine_virtuelle)) mais le plus probable est qu'elle n'existe pas, on parle de Java quand même.

C'est juste multiplateformes, normalisé (plus ou moins mais c'est le boulot du w3c), non lié à une implémentation, plus simple à développer, plus sécurisé…

Jouer avec la webcam en HTML5 est facile, on ne peut pas en dire autant du dev bas niveau qu'il faut réaliser sur chaque plateforme courante.

Je ne trouve pas ça déprimant, au contraire :-)

Les mauvaises performances de la VM d'Oracle ne sont pas liées à l'architecture de Java, mais à son implémentation. Mono et Dalvik sont très similaires et n'ont pas ces problèmes.

Pour la consommation mémoire importante, le problème est qu'il est souvent préfér d'utiliser une gestion de la mémoire automatique avec garbage collector au lieu de laisser le développeur gérer la mémoire. Ça a les mêmes défauts que du Perl, du Python, du JavaScript, du Ruby… Personnellement je n'aime pas trop non plus quand c'est pas obligatoire, mais ça facilite le développement et le coût de la mémoire est quand même très faible (même sur mobile).

Après c'est sympa les eeePC avec Intel Atom, mais ça n'existe plus. Le marché est mort et s'est fait remplacer en vitesse par les tablettes ARM qui utilisent Java et qui sont pourtant plus performantes à l'utilisation.

Tu peux continuer à utiliser des machines dépassées techniquement en utilisant des veilles technologies de développement qui ont fait leurs preuves, mais ne reproche pas à l'informatique d'évoluer pour mieux répondre aux besoins des utilisateurs.

Linux a raté le desktop mais a réussi le mobile à la fois cotés client et serveur.
GNU/Linux a raté le desktop et n'existera certainement jamais sur mobile quand on voit le conservatisme de ses utilisateurs.

On est pas obligé de reproduire l'histoire de LinuxFR en J2EE (http://linuxfr.org/users/ploum/journaux/linuxfr-en-j2ee).
Le bullshit autour du Java n'est pas lié à son architecture que je prenais comme exemple. D'ailleurs, Android utilise massivement Java et je n'ai pas l'impression que ça soit vraiment gênant.

Plus globalement, j'ai l'impression de troller avec des personnes qui ne veulent pas admettre que l'informatique évolue vers des technologies différentes de celles qu'ils maîtrisent. Je peux citer n'importe quel argument avec des exemples, vous allez toujours dire «ça pu c'est pas comme en 1990».

Il y a quand meme des differences majeurs dans le language qui rendent juste impossible d'avoir la meme simplicite pour la compilation et si une tache est plus complique, elle prend plus de temps et reste forcement plus lent. Surtout que la compilation/optimisation, ce n'est pas une tache simple a la base…
Oui, mais je dis que ça va être négligeable. La perte de performances par l'absence de compilation, le fait que JavaScript soit un langage à prototypes, à typage dynamique etc… Tout ça sera négligeable pour la majorité des applications.

C'est comme la différence entre du C++ et du Java aujourd'hui. La perte de performances due à l'architecture de Java (machine virtuelle, fonctions toutes virtuelles, optimisations plus faibles) est négligeable pour la majorité des applications.

Et ton interface web, elle tourne dans quoi ? Une application native :-D Tu peux faire logiquement plus en natif que avec du web. L'inverse etant faux !

Sans blagues… Mais à temps de développement égal, tu fais bien plus de choses en web. Tu peux t'amuser à réinventer la roue, mais personnellement je considère qu'il y a des gens qui l'on bien mieux fait que moi.

Pourtant Android, c'est du Java, c'est portable, ca marche partout ! Il y a dix ans, on me disait que ca serait vrai avec le Java…
Java est portable. Swing et compagnie ne sont pas portés sur Android mais c'est pas plus mal. On ne développe pas une interface d'application mobile comme une application de bureau d'il y a 15 ans. Maintenant la partie métier de ton application est portable.

En fait, j'ai l'impression que tu n'aimes pas le web et que tu aimerais que les utilisateurs préfèrent les CLI en C. Peut-être que tu considères que le design de ce type d'applications est plus beau. En attendant, l'utilisateur il aime bien cliquer sur un lien et que ça fonctionne.

On va dire que c'est la fatigue :D

Les performances 3D sont bof mais en 2D c'est quand même très correct.

Le mec qui est dans le cantal et qui n'a pas l'ADSL il attendra que ça charge, mais il a l'habitude. Et il ne va pas attendre plus qu'avec le téléchargement du jeu natif. Il faut peut-être plus faire attention à la taille des données qu'un jeu natif, mais c'est dommage de s'arrêter à ça.

La consommation mémoire ne va pas être forcément excessive. Sur le benchmark entre V8 et Mono, la consommation mémoire est en moyenne deux fois plus faible pour V8. Le rendu du navigateur risque de prendre lui aussi un peu de mémoire mais franchement c'est pas ça le principal.

Pour une LAN, rien n'empêche d'héberger le serveur en local. Et les websockets permettent une bonne latence en général.

Je vois pas le rapport avec les onglets youtube et compagnie. Le manque de mémoire à cause des autres applications ouvertes, c'est pareil en natif ou en web…

Pour les raccourcis clavier il y en a moins, mais jepense qu'un jeu qui arrive à utiliser tout les raccourcis clavier disponibles a certainement un problème de conception au niveau des interactions avec l'utilisateur.

Pour le débogage, je ne pense pas que ce soit différent qu'avec d'autres technologies. Webkit propose des outils de développement très complets avec un débogueur tout à fait fonctionnel.

Je ne vois pas trop ce qu'il perd en liberté en utilisant un outil dont il n'a pas les sources au lieu de ne pas pouvoir utiliser son ordinateur.

Et tout le monde ne peut pas choisir son ordinateur et ses composants.

Je te conseille de te tourner vers le web.

Le web va te permettre de bénéficier de librairies nombreuses et performantes, de la plus grande communauté de développeurs. Tu vas pouvoir faire un jeu multiplateformes du premier coup ce qui te permettra de le partager efficacement. C'est plus simple de cliquer sur un lien que d'installer Python.

Si tu n'aimes pas le JavaScript, tu peux utiliser un des 12 000  langages qui se compile en JavaScript (voir cette liste https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS). Je tiens juste à mentionner Emscripten qui est un compilateur vers JavaScript te permettant par exemple d'utiliser des outils en C.

En ce qui concerne les performances, les machines virtuelles JavaScript sont maintenant pas trop mauvaises pour un tel langage (interprété, prototypes, typage dynamique…). Même si un bench n'est pas une valeur universelle, regarde http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=csharp pour la différence entre V8 et Mono par exemple. Pour le rendu, les navigateurs récents peuvent utiliser le GPU de manière transparente, et les performances sont alors excellentes.

Ce n'est pas un hasard si de plus en plus de systèmes d'exploitations se tournent vers le Web (windows, tizen, firefox os, webos, etc…). Le jeu vidéo sur le web est peut-être encore un peu jeune et le marché n'est pas encore stabilisé (il suffit de voir le nombre d'outils en concurrence dans tout les domaines), mais te former sur ce domaine n'est à mon avis pas du temps perdu.

C'est peut-être plus pratique, mais les utilisateurs (les clients) n'aiment pas. Il faut voir le succès des applis mobiles : les versions travaillées graphiquement sont préférées aux versions qui utilisent uniquement les widgets natifs.

Si on regarde le top gratuit de Google Play sur les 250 premières applications (https://play.google.com/store/apps/collection/topselling_free), il n'y a que celles de google qui utilisent le thème de base.

Ça ne semble donc pas déranger les utilisateurs d'avoir une interface spécifique à l'application. Pour ma part, je considère normal que les interfaces de mes applications soient différentes. Que ce soit Blender, Chromium, Spotify, GVim, ils me semble qu'elles ont toutes une interface adaptée.

Après une jolie interface ne va pas rendre l'application pratique à utiliser, mais ça rajoute au moins un intérêt esthétique à l'application. Et ça, ça permet de faire la différence. Tu peux avoir une application avec des algos en O(n log n) au lieu de O(n), qui consomme peu de mémoire, qui soit codée proprement et testée, mais qui n'est pas utilisée. Car les utilisateurs ne le voient pas et s'en fichent, ce qu'ils voient c'est l'interface. Et si ta seule interface est un truc fait à l'arrache en GTK, ils vont préférer prendre l'application qui a la classe esthétiquement même si elle est moins bonne techniquement.

Oui on peut toujours, mais ça devient vite compliqué. Personnaliser l'affichage d'une liste en Swing n'est pas évident alors que ça se fait très facilement en HTML/CSS.

Et d'ailleurs très peu de développeurs le font. J'ai rarement vu une interface GTK vraiment personnalisée. En Qt c'est déjà un peu plus souvent le cas, peut-être parce que c'est plus facile pour le développeur. En Web c'est très facile de personnaliser son interface et c'est plus souvent réalisé dans une démarche graphique.

Malheureusement tout le monde n'est pas un bon graphiste et un bon ergonome, du coup les interfaces en HTML/CSS sont parfois moins bonnes qu'un bon toolkit graphique des années 90.

Cela veut dire qu'ils ont porté GTK (et peut-être Qt en mode raster) sur SurfaceFlinger ? Ou c'est un X11 qui tourne en fond ?

Les problèmes de performances ne sont que temporaires. Je pense que d'ici quelques années, la différence de performances entre Dalvik (la machine virtuelle d'Android) et V8 (la machine virtuelle Javascript de Google) sera négligeable pour la majorité des applications.

Pour l'interface en elle même, la différence vient aussi du fait qu'il est possible de faire tout ce que l'on veut en web, alors qu'en natif on est limité aux choix des gens qui ont développé le toolkit. Ces choix sont souvient meilleurs, mais c'est pas forcément adapté à toutes les utilisations.

C'est vrai que créer une application web aujourd'hui est plus pénible, mais ça vaut le coup. Car ton application Android ne fonctionnera que sur Android alors que ton application Web fonctionnera partout (enfin tout ce qui fait tourner webkit :p).

Si on autant d'applications pour téléphone mobiles intelligents, c'est qu'il y a un marché pour ça. Ça permet d'être dans l'annuaire (le magasin d'apps), d'avoir un avantage marketing sur les concurrents, et de vendre des applications qui ne font pas grand chose. Mais une bonne partie de ces applications se contentent d'afficher un navigateur web en plein écran et les autres sont en générales beaucoup moins complètes que le site web équivalent.

J'ai jamais rien compris à l'utilité de Backbone.js.

On peut lire que ça permet de faire plein de trucs cools, mais ça ressemble à une usine à gaz vide. Est-ce qu'il y a une documentation simple et efficace, avec des exemples concrets ?

J'ai acheté du 16:9 parce que c'est moins cher et que c'est plus pratique pour regarder des films et jouer (full hd 16:9).

Et comme j'en ai deux, ça permet d'avoir plein de colonnes pour coder avec plein de fichiers ouverts et visibles en même temps.