un_brice a écrit 1165 commentaires

En ce moment j'ai de temps en temps des petits soucis de chargements sur Chromium 17 (images avec le symbole d'erreur de chargement qui fonctionne si je recharge la page, page qui reste blanche, ...).

C'est pas la 16.0.912.63 la version stable de Chromium ? À priori là tu es sur une version alpha (enfin, « dev » dans la terminologie du projet).

Sur ce sujet, un article de blog (en Anglais) par Wingo (développeur pour Guile) explique une partie du fonctionement de V8, la machine Javascript de Chrome. Je trouve vraiment impressionnant ce qu'ils arrivent à faire avec un langage qui est à la base pas franchement conçu pour les performances. J'espère qu'un jour ce niveau d'optimisation sera atteint avec des langages dynamiques plus « classiques », comme Python ou Ruby.

This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.

Je vois absoluement pas le rapport entre sécurité et accélération GPU. C'est absoluement pas incompatible.

C'est pas tellement la sécurité le problème, mais le multiprocessus (enfin, c'est lié). Déjà, la création d'un contexte OpenGL prends 8MB de RAM, par processus sur certains périphériques. Mais surtout, Android est multifenêtre (y'a la status-bar, parfois une surimpression comme le menu du bouton On/Off ou une notification « Toast » …). La composition des différentes fenêtres est accélérée OpenGL, car c'est ce qui est le plus critique d'un point de vue performance. Donc pour avoir la composition OpenGL entre fenêtres et de l'OpenGL dans une fenêtre, il faut avoir un GPU qui gère le fait d'avoir plusieurs contextes OpenGL. Or c'est très récent. Et le coût de changement de contexte reste très élevé. Ce n'est donc que récement que le fait d'avoir plusieurs contexte est devenu possible et rentable, d'où l'absence d'accélération matérielle au sein d'une fenêtre jusqu'à récemment.

Du moins c'est ce que dit Dianne.

mais ça n'explique toujours pas pourquoi on a ce sentiment de saccade sur Android
là où iOS ou WP7 paraîssent fluides

Bien sûr, je commencerais par dire que chez-moi-ça-marche.com .
Du coup de mon point de vue, la vrai question est de savoir pourquoi les gens continuent à acheter des téléphones qui laguent, sachant que certains ne laguent pas (cf plus bas). Je suppose que c'est plus cher et que les gens sont mal informés. Comme avec les PCs sous Windows finalement (cf « Pourquoi Vista ça lague ? »).

Ensuite, à hardware équivalent, le post explique pourquoi Android est/était moins fluide : pas de rendu par titles dans le navigateur, capacités différentes (multifenêtre dans le cas d'Android, monofenêtre dans le cas d'iOS et à priori de WP7), résolution différentes (720×1280 pour un Galaxy Nexus)… les pistes sont nombreuses. Le message les analyses bien de mon point de vue.

Pour parler sur des exemples plus concrets de mobiles, mon premier Galaxy S avait un problème dû à l'utilisation d'un FS basé sur Fat32 pour le / (sic, vive Samsung). Changer le FS a réglé le problème, normalement les dernières version du firmware officielles le fixent également.
Sur mon LG Optimus 2X, j'ai directement installé CyanogenMod et n'ai pas eu de problèmes de lag (enfin, sauf les I/Os quoi).
Je dirait que ça dépends du device.

Sur un ton plus annecdotique, chaque jours pendant 10 jours, 10 applications (propriétaires) sont à 10 centimes sur l'Android Market.
On en est au septième jour, et malheureusement aujourd'hui l'une de ces applications n'est pas accessible en France. Notons enfin que certaines applications restent d'un jour sur l'autre.

Pour ceux qui auraient manqué la saga que représentent les liens cités dans « iOS restera plus fluide que Android : faits ou allégations ? ». Voici la version courte.

1. Dianne, ingé de Google, explique pourquoi Android roxe (premier lien dans cette phrase de l'article).
2. Andrew, un ex-stagiaire de Google nouvellement chez MS explique pourquoi Android pue (deuxième lien dans cette phrase de l'article).
3. Depuis un nouvel épisode est paru : la réponse de Dianne. Cette réponse a depuis acceptée par Andrew.

Tout est bien qui fini bien donc :-)

Juste pour info, GWT (une suite qui compile du Java vers du Javascript et propose un système de RPC permetant de comuniquer facilement avec un serveur ou un mobile sous Android) a un concept sympa dans le genre mais appliqué aux GUIs.
L'idée est d'avoir une classe, appellée ActivityMapper qui réalise cette fonction d'associer des adresses (des « places ») à des « activités ». Les activités étant typiquement un ensemble constitué d'une vue (des widgets) et d'un présenteur (la logique de la vue, qui peut être identique pour différentes vues réalisant la même fonction). Le framework aide en implémentant tout ce qui est gestion de l'historique, recyclage des vues etc.

Ça c'est pour les similitudes. La grosse différence c'est que tout se passe côté client. Ce qui est parfois un plus quand on fait une application dans le navigateur, mais est certes gros inconvénient quand on fait un site.

Il reste qu'en utilisant GWT et en consultant quelques tutos associés, j'ai découvert des manière d'organiser une GUI qui me semblent sympathiques quelque soit le langage (MVP, le couplage faible grâce à un EventBus…).

Je dois dire que certains passage de la dépêche m'interpellent. Je fais référence à :

Comme annoncé dans la nouvelle de sortie de LLVM 2.9, le système de type a été entièrement revu. […] En plus de cet inconvénient, les types opaques, une fois résolus, impliquaient un parcours complet de tous les types et valeurs existantes, ce qui provoquait de nombreux bugs.

Et :

Le système de gestion des exceptions a été entièrement revu. Le nouveau système permet de corriger un grand nombre de bugs.

Tant de bugs ? Sur des éléments aussi importants ? C'est inquiétant. Surtout sur cinq « nouveautés dans le cœur de LLVM » décrites.

Plus pour chipoter :

LLVM gère désormais la prédiction de branche et __builtin_expect sous forme de métadonnées dans la représentation intermédiaire.

Ça semble un peu élémentaire comme fonctionalité non ?

Notons que le code source d'Android 4.0.1 vient tout juste d'être publié

Le bruit court que la Transformer Prime sera directement vendue sous cette version à sa sortie, contrairement à ce qui était initialement prévu et à ce qui est annoncé dans la news.

Je suis un peu lourd, mais j'ai fait mon RTFM, et rien de ce que j'ai trouvé ne me semble justifier l'appellation de "World's first fully virtualized operating system". Surtout si on fait la distinction virtualized/containerized.

À moins de considérer qu'ils entendent par là "World's best fully virtualized operating system" et là c'est un troll sans fin autre débat (qui commencerais par contester la justesse du qualicatif des « simples interfaces virtuelles » et à rappeller les fonctionalités exclusives de Linux en la matière ;-) ).

est-ce que la devise « don't be evil » disparaîtra comme par enchantement

"Don't be evil" fait toujours partie des consignes données aux Googlers. Et ça intervient dans les décisions.
Après ça veut pas dire « soit un bisounours » et je suis d'accord que certaines décisions (le fait d'opérer en Chine par exemple) sont contestables. Il n'empêche, ça a pas disparu.

Si je ne m'abuse, les zones c'est plus de la conteneurisation que de la virtualisation. Et pour ce que j'y comprends, conteneuriser/virtualiser le réseau Linux le fait.
Après peut être que cette version est la première à avoir certaines fonctionnalités sympathiques dans le domaine de la conteneurisation. C'est possible même si j'ai pas eu l'impression en regardant le changelog.
Mais de là à dire que c'est le « World's First fully virtualized operating system »… ça me semble un peu excessif.

Ou alors, ils disent « World's First » au sens de « cette version est la meilleure au monde » et pas au sens de « cette version est la toute première ». Ou ils font allusion à une version précédente (auquel cas c'est toujours contestable).

En ce qui concerne les mises à jour, cyanogenmod les porte avec succès sur de nombreux téléphones. Personnellement j'achète que des téléphones supportés par ce projet, et ça me permet d'être plus tranquille par rapport à la pérennité de mon achat.
Bon après, pour Madame Michu c'est pas ça. Mais il a fallu la menacer de mort pour qu'elle fasse les mises à jours de son PC, et elle s'attend pas à avoir Windows 7 gratuitement à sa sortie.

Toutes mes excuses. J'ai vraiment dit de la m*rde.

La bonne nouvelle est qu'il semble que la version développeur de Chrome intègre malgrès tout un workaround, même si ce n'est pas celui que je croyais.
(Source : the Register, http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/ )

Ça fait quelques temps que Chrome interdit l'inclusion de Javascript non authentifié par les pages HTTPS (en tout cas, la beta le fait depuis plus d'un mois ). Un message apparaît demandant de valider manuellement le chargement du script.
Google Chrome et Chromium ne devraient donc pas être vulnérables, ce qui illustre une fois de plus le soin apporté à la sécurité de ces navigateurs.

Je vais dire quelque chose de très cynique : le DRM d'Adobe est à l'heure actuelle la seule chose qui me permet d'avoir des livres numériques non restreints.
En effets, les éditeurs sont rassurés par la présence d'un DRM, et ne publient qu'avec DRM. Hors celui-là est populaire, et comme tu le dit, facile à craquer. Les diçaïdors sont content et moi aussi (je pense même avoir le droit de le cracker pour l'interopérabilité mais je suis pas sûr).

Alors certes, ça ne devrait pas être comme ça. Et c'est peut être illégal. Mais ça marche et surtout c'est moral (de mon point de vue, probablement de l'avis général ici).

Si tu propage trop l'idée qu'Adept est inefficace, les éditeurs en utiliseront un autre et les gens comme nous n'auront plus que le choix entre ne pas acheter les livres qu'ils téléchargent ou avoir du DRM.

Aussi je te propose de retirer cet argument de ton argumentaire quand tu contacte les éditeurs. Avec un peu de cynisme je te conseillerais même de les encourager à utiliser ce format de DRM au détriment des autres, en disant que c'est le plus universel et ainsi de suite… Je pense qu'un DRM snakeoil fait plus de bien que de mal.

Même en dehors de l'autoboxing, le switch peut est (si c'est bien fait) implémenté par quelque chose de bien plus efficace qu'une succession de tests, c'est sans doute l'une des raisons pour lesquelles il a un mot clef dédié. Autant dans le cas des entiers c'pas bien grave, autant pour des chaînes de caractères ça peut être critique (O(ln(nombre de possibilités)) au lieu de O(nombre de possibilités*taille de la chaîne)).

Si on utilise un truc à base d'equals ça marche pas, et ça fait des appels de méthode « magiques » qui ne sont pas écrits dans le code source mais dans le langage (bon, OK, le nouveau système de try-with fout ça en l'air mais c'est quand même plus explicite de mon point de vue)

Exception faite des mots de passes, qui eux sont cryptés. Ce qui est bien, mais pas top.

Le gars de Nginx dit que V8:
* termine le process quand il n'y a plus de RAM (ce qui gène NginX car il est mono-process)
* nécessite 2ms pour la création d'une requête (ce qui gène NginX car il est mono-thread)
* ne supporte la compilation native que pour amd64, i386 et arm

Ces arguments semblent indiquer que V8 n'est pas adapté pour remplacer les modules permetant de scripter NginX genre lua-nginx-module .

Ces arguments n'impliquent pas :
* que V8 n'est pas adapté pour scripter des applications en général
* que V8 n'est pas adapté pour créer un langage de script serverside

Un bémol tout de même :
- Y'a que les 48 dernières heures ('fin comme dit le gars, en admettant que la version du code qu'il a analysée soit bonne).
- Quand tu allume le téléphone pour la première fois, il te demande de manière très explicite si tu l'autorise à comuniquer à Google ces enregistrements (du moins, le mien le demande).

Perso je me méfie bien plus de SFR, LCL et consorts que de Google ou Facebook. Les premiers me demandent rien, ont une conception toutes particulière de la sécurité, pas de politique publique quand à la vie privée… Et accès à mes moindres déplacements, requêtes sur Internet, SMS voir même mon shoping dans le cas de la banque.
Google a une page pour effacer toutes les données non-anonymes https://www.google.com/dashboard/ , j'attends de pouvoir en faire autant ailleurs.

Ce lien est très intéressant, mais malheureusement un peu ancien :
- La partie sur le NDK n'a plus cour, on peut peut écrire des applications 100% natives depuis le dernier NDK.
- La partie sur la politique de Nokia VS celle de Google n'est plus d'actualité non plus vu le revirement récent de Nokia et la déclaration de Google en faveur de laisser les utilisateurs rooter leur système.

Enfin notons que la partie sur le fait d'être root spécifie bien que ça dépends du device et du choix du vendeur.

Il ne s'agit pas de modifier l'OS. Pour remplacer l'appli de SMS (par exemple) on installe simplement depuis le market une application qui fournit le service « envoi de SMS ».
Ensuite la prochaine tentative d'envoi de SMS demande quelle appli utiliser. Si l'utilisateur choisit la nouvelle, et coche « Utiliser par défaut », l'appli fournie n'est plus utilisée (même si l'opérateur interdit de modifier le système et donc de la désinstaller).
C'est un peu comme sous Windows XP où on peut installer Chrome facilement même si désinstaller IE est plus complexe.

Exemple d'applis de remplacement :
SMS : https://market.android.com/details?id=com.handcent.nextsms
Clavier : https://market.android.com/details?id=com.touchtype.swiftkey
Écran d'accueil : https://market.android.com/details?id=com.larvalabs.slidescr(...)

Ces applis consistent simplement en une utilisation de l'API officielle, qui est bien plus puissante et permet aux applications tierces de creuser l'écart entre Android et les autres plateformes en terme de fonctionnalités.

La liste est en fait infinie ! La non-disponibilité de nombreuses API, rendent impossible sous WP7 de nombreuses choses qui sont possibles sous Android grâce à des applis tierces.
Ceci est amplifié par le fait que les applications fournies avec Android sont remplaçables. Je fait de nombreuses choses que les applis de base ne savent pas faire, mais que celles que j'ai installées à la place font bien.
Alors tu me diras, Mme Michu ne sait pas remplacer son appli d'envoie de SMS. Mais Kevin Michu (son fils) si.
C'est comme Windows : la plupart des gens savent pas installer Google Chrome ou VLC, mais ils sont bien content quand leur fiston kisiconnait l'a fait.

Pour donner un peu de corps, quand je parle d'applis impossibles sous WP7, j'en ai une appli (GTalkSMS) qui me permet de contrôler mon téléphone à distance en lui parlant via Jabber. Ou une autre appli qui envoie tout mes SMS sur un serveur IMAP de mon choix pour que je puisse les lire sur mon ordinateur (SMS Backup). Et j'ai changé mon écran d’accueil pour un autre plus attrayant (Go Launcher Ex, y'en a d'autres «à la WP7» si tu aimes). J'ai une appli qui me permet de mettre mon téléphone hors ligne à certaines heures, …
Enfin bref, j'arrête là ;-)

> Quand a ton Android, nombre de carriers font de meme et bloquent la possibilite d'installer des softs hors-market.
Pas en France à ma connaissance (enfin si mais chez les gens que je connait y'avait juste une case à cocher dans les options pour le réactiver). Du reste, c'est plus une caractéristique d'Android mais de l'opérateur.

> Et *sans* passer par les services en ligne Google ?
Google a pas un rôle particulier hardcodé dans le téléphone (bon, sauf qu'il fournit le Market par défaut, et un ou deux autres trucs), tu peut passer par Facebook si tu préfère :-P

Plus sérieusement, tu as une foultitude d'apps pour exporter tes contacts au format CSV, pour uploader tes SMS sur un compte IMAP… Un grand nombre sont libres.