flan a écrit 1829 commentaires

Pourquoi être parti de GWT en particulier ?
Je ne trouve pas les exemples particulièrement sexy, personnellement.

Cappuccino, qui utilise un peu la même idée (compiler un langage vers du javascript), mais le résultat est autrement plus joli (à mes yeux, en tout cas). En plus, il permet de réutiliser un IDE complet (XCode, en l'occurrence) pour dessiner l'interface graphique sans écrire une ligne de code, l'utilisateur se contentant de connecter les événements au code.

Ce n'est pas évident de convertir une grosse base de code existante en Python 3, voilà pourquoi.

Le mouvement de transition des bibliothèques les plus connues vers Python 3 a réellement été amorcé assez récemment, au final. À mon avis, une partie est due à l'ajout dans Python 3.3 du support du préfixe u'', comme en Python 2.7, qui simplifie beaucoup ce portage.

Mais logiquement, si la demi-vie est longue, alors les déchets sont faiblement radioactifs.

Et migrer de 25cm en 100 000 ans, ça reste quand même raisonnable…

Des fuites ? Il me semblait que les déchets radioactifs étaient sous forme vitrifiée ? Donc plutôt pas évident à abîmer, bien loin de tous les produits chimiques nocifs qui sont dans des décharges naturelles et qui ont une durée de vie bien plus importante.

Rosetta, ce n'est de l'émulation pure et dure. Si je ne me trompe pas, c'est un peu plus fin que ça.
Les bonnes applications OS X utilisent énormément le framework Cocoa (qui est quand même plutôt complet), et le code du framework était en x86. Du coup, si une application passait 90% de son temps dans le framework Cocoa, il n'y avait que 10% de PPC à émuler.

Accessoirement, j'ai du mal à croire qu'on fasse une transition vers une nouvelle archi qui fournisse moins de performances, surtout que la consommation commence à être raisonnable pour du x86 : un test récent montre qu'un MacBook Air possède plus d'autonomie — 14h pour du surf ! — qu'un iPad, alors qu'il est beaucoup plus puissant. Au passage, pour les batteries : 7 150 mAh pour le MBA, et 11 666 mAh pour l'iPad (j'avoue, ça m'étonne un peu).

Oui, sur le fond, c'est certainement vrai. Mais à nouveau, l'exemple d'OS X montre que ce n'est pas si gênant que ça. Ils ont bien fait leur transition PPC vers x86 sans être vraiment gênés.

Et encore faut-il que l'ARM décolle vraiment sur le desktop pour qu'on voit une différence, pour l'instant ce n'est pas gagné que l'ARM rattrape le x86 en termes de perfs.

Du coup, ils le placent pendant la récolte des dons. Ça fait toujours ça de pris :D

Franchement, que ce soit du proprio ou du libre, ça ne change rien. L'écosystème d'OS X possède beaucoup de proprio, et on ne peut pas dire que ça a gêné l'émergence de la logithèque sur iOS.

D'ailleurs, croire qu'il suffit d'une recompilation pour passer d'un logiciel pour ordi à un logiciel pour téléphone est une grosse erreur à mon avis. Pour avoir un truc utilisable, il faut complètement repenser l'interface.

On ne doit pas avoir fait les mêmes maths, alors, parce que j'ai toujours utilisé beaucoup de caractères romains en cursifs.

Personnellement, ce genre de licence me convient très bien pour quelque chose fait par l'Administration, et je ne vois pas pourquoi elle devrait changer la licence.

Ça ne devrait pas te plaire : Mail, sur OS X.

Tu veux dire qu'avec un octoœur et une appli web, tu retrouves les perfs d'un client lourd avec un Pentium 4 ?

À se demander qui est vraiment le client lourd et qui est le client léger !

De mon côté, je suis toujours partagé entre les deux…

• client léger plus facile à déployer
• toujours présent sur un poste quelconque
• pour les gens qui bossent sur des postes déconnectés d'internet, ce n'est pas ultra pratique :D (et déployer un serveur web est quand même plus compliqué que déployer un client lourd)
• soit on confie ses données à quelqu'un d'autre, soit maintenir un serveur web (être admin d'un serveur, c'est compliqué et ça implique des connaissances en sécu)
• c'est rare de pouvoir faire interagir les applications entre elles
• je n'ai jamais vu un webmail à la hauteur de mon client mail (idem pour le calendrier, l'éditeur de texte, etc.)

Je fais des apt-get update && upgrade, mais s'il faut fermer ma session, alors tant pis si la màj n'est pas appliqué (je compte sur le prochain plantage d'Ubuntu pour remettre les choses d'équerre :D). Au boulot, le poste n'a pas accès à internet, et chez moi, les màj (sur OS X) demandent rarement de redémarrer l'ordi et du coup il peut facilement rester 6 mois sans que la session soit refermée.
En gros, je fais les màj quand je déménage, que j'ai une coupure électrique trop longue, ou que j'ai un problème avec l'onduleur.

Je pense qu'Apple fait son beurre sur le matériel et des marges « ridicules » sur les logiciels maison (comme OS X qui est vendu à 20€…). Par contre, c'est sûr que le logiciel n'est là que pour vendre le matériel. Et quand on parle de logiciel, il faut penser à l'ensemble : OS X offre un très grand nombre d'API permettant une excellente intégration du logiciel à l'OS (et rendant difficile les portages, dans un sens ou dans l'autre), mais aussi entre différents logiciels, et entre différents matériels. Pour le coup, je pense qu'Apple est vraiment le seul à avoir porté l'intégration aussi loin entre toutes ces composantes.

C'est là tout le défi, je trouve : trouver une utilité pour pouvoir en vendre suffisamment :)

Personnellement, j'ai horreur de devoir fermer ma session. Chez moi, je peux laisser ma session ouverte pendant des mois. Par contre, au boulot, je peste fréquemment quand X plante (ça arrive bien une fois par mois), parce que je perds toutes mes fenêtres et terminaux…

Un truc pas mal, c'est la pseudo-localisation.

Pour faire simple, au lieu d'écrire « Account Settings », on écrit « !!! Àççôûñţ Šéţţîñĝš !!! ». Ça combine plusieurs avantages :

• caractères spéciaux
• marqueurs de début et de fin, pour voir si le texte est tronqué
• le texte est plus long
• on reconnaît le texte d'origine

Il doit être assez facile de générer des fichiers de pseudo-localisation à partir des fichiers .mo classiques.

C'est quand même dommage de devoir fermer sa session.

(Aurais-tu quelque chose contre le flan ? :o)

Par défaut il n'existe pas. Il faut l'activer pour qu'il soit présent. Personnellement, je l'ai mis, ça simplifie le pointage.

Heureusement !

Y a des mapping clavier adaptés pour ça, qui n'ont pas besoin de reconfiguration… Je doute sincèrement que les gens aient besoin de 5 000 caractères sur leur clavier.

Accessoirement, Mac OS X gère de façon native la recomposition automatique des caractères (on tape oe, et c'est transformé automatiquement en œ). Ça a l'avantage de fonctionner également avec des abréviations que l'on aura spécifiées.

Personnellement, j'ai tous les caractères que je veux sur mon clavier (y compris «»œæ“”, bref tous ceux qui me permettent d'avoir une typographie qui soit un minimum correcte), ça ne m'a pas pris beaucoup de temps, sans compter que j'ai un clavier assez personnalisé (entre autre un mélange d'AZERTY et de QWERTY).

Tu peux le faire assez facilement avec un mapping clavier fait maison (via le logiciel Ukelele).

Le look & feel d'un OS ne se résume pas à un joli thème. C'est aussi tirer parti de toutes les ressources de l'OS.
Pour reprendre l'exemple d'OS X que je connais mieux, une appli bien intégrée va utiliser les API pour les animations 2D/3D (ce sont des fichiers .qtz qui sont réutilisables dans les autres applications), pour le carnet d'adresse, le correcteur grammatical et orthographique, pour la synthèse et la reconnaissance vocale, la gestion des secrets (mots de passe, tokens PKCS11, clefs privées, certificats, …), les images et musiques, le mode plein écran, les raccourcis clavier (modifiable dans n'importe quelle appli Cocoa)…

On peut sûrement faire une liste équivalent pour Linux et Windows (enfin, probablement pas aussi complète, par expérience), mais je connais moins le sujet.