flan a écrit 1805 commentaires

C'est également celle que j'utilise pour mes (mini) projets.
Après, en soi, je n'ai rien contre le proprio, je n'aime d'ailleurs pas l'idée qu'on oppose libre et proprio sur un plan moral. Par contre, j'aime l'idée de partager ce que je fais avec les autres, par principe. Et la Cecill-B permet ce partage assez facilement à mes yeux.

J'ai installé la Beta 5 chez moi, et je n'ai vu qu'on ne pouvait faire de l'authentification que par mot de passe. Peut-on envisager d'autres types d'authentification, genre Kerberos ou certificats, pour les machines et les utilisateurs ?

Pas besoin de lecteur de carte à puce, cela fait très longtemps qu'on sait faire des « clefs USB » qui font de la crypto asymétriques (en général, des clefs RSA jusqu'à 2 048 bits). Ou alors je n'ai pas bien compris de quoi on parlait…

18€ chez Gooze : http://www.gooze.eu/epass-2003

C'est sûr, ça n'existe pas, non pas parce que ce n'est pas possible, mais parce que MS n'en a pas le besoin.
Il me semble cependant que le kernel de Windows Phone est particulièrement léger.

Oui, mais ça ne répond pas à ma question :D

Comment peut-on dire que c'est plus « fun » et « humain » d'avoir des blocs délimités par end ou de pouvoir appeler une méthode sans les parenthèses ?

Après, sur le côté plus technique, je trouve qu'il y a vraiment peu de différences entre les deux, à part un peu de sucre syntaxique. Sauf le coup des parenthèses facultatives, qui enlève bêtement un côté super sympa de Python, le fait de pouvoir faire référence dans une variable à une fonction.

Sinon, je suis bien d'accord avec le message https://groups.google.com/forum/?fromgroups=#!msg/comp.lang.python/xBWUWWWV5RE/gyJRB9cihAIJ

Sans compter qu'actuellement, c'est tout de même bien plus simple de faire table rase du passé, au moins sur les ordis fixes : on peut se permettre de dire aux utilisateurs de prendre une VM (ou équivalent) pour utiliser les vieux programmes.

Ainsi, sur OS X, on peut faire (ou on a pu) fonctionner des logiciels conçus pour une version totalement différente (applis Mac OS 9 dans OS X via Classic), pour un processeur différent (applis PowerPC sur x86 via Rosetta), ou pour un OS différent (applis Windows dans une VM) de façon quasiment transparente ; c'en est même assez bluffant pour les applis Windows en mode intégré (elles se comportent vraiment comme des applis Mac).

Du coup, on peut parfois faire bien avancer les choses sans prendre la compatibilité en compte tant que les développeurs suivent le mouvement, et à moindre risque vu que le service est toujours rendu pour les utilisateurs.

Surtout sur cette phrase : « Sa principale caractéristique est de mettre en avant les besoins humains avant ceux informatiques, et notamment le fun et la productivité. »

C'est des arguments qui reviennent souvent quand on parle du Ruby, et franchement je ne vois pas en quoi c'est « fun » et en quoi il est plus « humain » qu'un autre langage. Les exemples que je vois me font quand même beaucoup penser à du Python, et ce dernier n'a jamais mis en avant ces aspects-là. D'ailleurs, j'ai un peu du mal à voir les avantages de l'un par rapport à l'autre (mis à part leurs catalogues de projets respectifs).

… tu peux investir dans un token USB (ou un lecteur de carte à puce). Ça doit coûter dans les 20€ environ, et ça te permet de stocker une clef privée et un certificat, que tu utiliseras pour te connecter à un webmail.

Comme ta clef privée ne quitte pas le token (les joies du PKCS11), ça devrait être bon.

Je vais essayer d'avancer un peu d'abord :)

Si je ne me trompe pas, le module Python "toto" est toujours dans le dossier toto/, qui contient un fichier toto/__init__.py.

Si je mettais un dossier src/, on se retrouverait avec un dossier src/ contenant uniquement un dossier toto/. Je trouve ça bof.

Quant à data à la racine, c'est nettement moins pratique pour y faire référence. Quand tu as toto/data et toto/__init__.py, data/ est toujours au même niveau que init.py (donc on peut calculer facilement son chemin absolu).
Par contre, si tu mets data/ à la racine, en mode développement data est à init.py/../data. Et quand il sera installé, où est-il ? Aucune idée, mais pas au même niveau en tout cas (vu qu'il serait mélangé avec les autres modules Python).

Tu ne fais pas la différence entre un CMS et un jeu vidéo ? :D

Est-ce la solution recommandée ? Pour moi, on est censé utiliser crontab -e, qui est inutilisable via des scripts.

(oui, pour moi la possibilité de configurer grâce à des scripts est vraiment pratique, mais je comprends que ça ne compte pas pour tout le monde)

Je ne comprends pas pourquoi tu opposes fichier texte et GUI.

Je trouve quand même que manipuler cron via des scripts (ce qui est obligatoire dès qu'on veut mettre en place des outils du genre puppet / salt / …) se résume à enchaîner les hacks crades et non fiables.

Je ne connais pas systemd mais un peu plus launchd, et avoir à poser un fichier (éditable sans problème via des scripts, sans avoir à coder un parseur différent à chaque fois) par commande à lancer est parfois bien pratique comparé à cron.

J'ai très peu utilisé Word, mais le mode « plan » est assez pratique (la mise en forme apparaissant à l'écran ne concerne que le fond).

LaTeX peut aussi être bien désagréable pour la mise en forme, surtout quand tu as des contraintes sur le nombre de pages. Je me souviens avoir dû rajouter une phrase pour diminuer le nombre de pages… Et devoir faire une compilation à chaque petite modif est tout, sauf pratique.

Ensuite, l'utilisation de Word permet d'avoir un document dynamique (sur lequel on travaille), pas simplement un truc à imprimer. Par exemple, avoir un rapport avec des graphiques dynamiques peut être intéressant : tu survoles un point sur un diagramme et tu as des infos supplémentaires.

Par contre, LaTeX permet l'utilisation des macros (au sens LaTeX, pas Word), ce qui est à mes yeux vital pour un document avec des variables (au sens mathématique du terme). Ça ne me viendrait pas à l'idée d'écrire en dur une variable qui est utilisée tout au long du document.

Je ne suis pas spécialement partisan de Word ou de LaTeX, même si j'utilise plus naturellement LaTeX.
Cependant, je trouve qu'en 2012, on pourrait avoir certains des avantages de Word :
- des documents qui ne sont pas figés
- avoir un rendu instantané
- une séparation du fond et de la forme minimale (elle ne sera jamais complète, même avec LaTeX)
- une mise en forme pour la rédaction
- une mise en forme pour l'exploitation
Tout en ayant les avantages de LaTeX :
- une mise en forme figée pour l'impression
- permettre l'équivalent des macros
- l'inclusion de sous-textes
- une biblio externe comme LaTeX (je crois que Word le fait, ceci dit)

Certes, on pourra dire qu'un traitement de texte n'est pas un outil de publication, mais en pratique, avoir un logiciel qui fait les deux est quand même bien pratique :)
Bref, il y a à mes yeux encore à faire sur le sujet.

S'il développe du Django pour des clients, il peut très bien ne pas avoir le choix du stockage. C'est une question intéressante à poser, en tout cas.

D'un autre côté, ce n'est pas très compliqué de faire de la mise en page avec Word, à partir du moment où on l'utilise correctement (en passant par les styles, par exemple).

De plus, pour faire une lettre toute bête (donc un document « jetable »), Word peut permettre d'aller assez vite quand on veut ajuster des détails sur la mise en page.

Pourquoi tant de haine ?

Donc pour toi, c'est une merde sans nom parce qu'*une* des représentations ne convient pas au monsieur… il aurait aimé une représentation XML qui est un peu moins verbeuse, mais dont il cache les graves inconvénients :
- impossible de retrouver le fichier d'origine (il suffit de voir qu'on ne peut pas dans son exemple faire la différence entre les différents types d'éléments)
- impossible de valider le fichier en utilisant une DTD
- encore moins possible de garantir que c'est une plist valide

Et accessoirement, il oublie qu'à la rigueur, on s'en fout de la représentation du fichier vu que c'est prévu pour passer par des parseurs de plist, pour obtenir une représentation utilisable.
En Python, j'utilise plistlib et hop, j'ai directement des objets Python que je peux manipuler comme je veux. Ou au contraire, je donne mes objets Python (dictionnaires, listes, entiers, …) et j'ai mon fichier plist directement (sans avoir à connaître la représentation binaire associée).
Avec sa méthode, impossible de faire la même chose.

Bon, il préfère la version binaire du Plist, en disant que c'est plus facile d'écrire un parser… Ça se voit qu'il n'a jamais dû en écrire un. Par exemple, le parseur plist XML de Python est plus simple que celui qui est proposé pour la version binaire.

En fait, il critique alors qu'il n'a absolument pas compris le but des fichiers plist, qui est de justement ne pas avoir à se préoccuper de la représentation physique et de ne manipuler que des objets natifs du langage de programmation.

Bref, dire que c'est une merde sans nom simplement parce que quelqu'un trouve qu'une des représentations possibles est un peu trop verbeuse à son goût, je trouve ça légèrement exagéré :o

Sinon, il y a la doc Python http://docs.python.org/3/library/plistlib.html

Le format n'a vraiment rien de sorcier, on en fait vite le tour avec quelques exemples.

C'est bien dommage que les plist fassent peur comme ça, les plist (property lists) ont pas mal d'avantages.
C'est à la base un format abstrait, qui peut être indifféremment écrit sous forme binaire, XML ou JSON (avec quelques limites sur le format JSON cependant).
- le format est bien documenté (bon, ok, il faut dire qu'il n'est pas franchement compliqué…).
- il y a des utilitaires pour le convertir d'une représentation à l'autre (du binaire à l'XML, par exemple), pour l'éditer à la main
- des libs existent dans différents langages (par exemple Python, ça fait même partie de la lib standard) pour lire et écrire des plist
- un utilitaire en ligne de commande (defaults) permet de modifier certaines valeurs
- il existe des utilitaires graphiques pour éditer plus facilement le contenu (quand le XML ou le JSON est un peu rébarbatif)

Au final, on se retrouve avec des fichiers de configuration super pratiques, vu que :
- pas de problème de syntaxe différente entre deux applications (ah, la joie des différences entre espaces et tab, surtout avec un éditeur configuré pour remplacer l'un par l'autre)
- besoin de lire la configuration d'un autre programme depuis son propre logiciel ? pas de parseur exotique à réécrire !
- besoin de changer une configuration depuis un script ? la commande defaults le permet sans souci.

Il manquerait peut-être un éditeur en ligne de commande, mais ça ne doit pas être très compliqué à coder.
Tous les fichiers de configuration (ou assimilables) sur OS X sont des plist (fichiers de conf, descriptifs d'une application, préférences de l'utilisateur, démons lancés par launchd, …), sauf les applis UNIX pures, naturellement.

Certes, cela ne permet pas les commentaires dans le fichier de configuration (à ma connaissance). J'imagine que l'idée pourrait être améliorée assez facilement.
Je ne dis pas que c'est la solution parfaite, simplement qu'avoir une seule syntaxe et qui soit utilisable via le shell, dans un éditeur ou via n'importe quel langage de prog est vraiment très pratique.

Encore faut-il que le 4K remporte un succès plus important que la 3D. Vu le gain apporté, ce n'est pas sûr.
Certes, en théorie, on a 2 fois plus de pixels (en largeur).

Cependant, une bonne distance pour regarder la télé donne une ouverture d'entre 20 (un peu loin) et 40° (un peu près).
L'œil humain a un pouvoir de résolution d'environ (1/60)°. Autrement dit, il n'est pas capable de distinguer plus de 1 200 pixels en largeur sur une télé vue avec un angle de 20°, et plus de 2 400 sur une télé vue avec un angle de 40°.

Du coup, si on regarde une télé avec un angle de 32°, on ne verra pas de différence entre la Full-HD (1 920 pixels de large) et la 4K (3 840 pixels).

Par contre, on aurait vu la différence avec une Full-HD en 16/9 et une Full-HD en 4/3 (l'œil ayant plutôt une vision en 4/3)…

Inciter à l'innovation : en quoi ? les webapp sont apparues sur les mobiles il y a quand même quelques années. Ce n'est pas parce que cela a fait un flop il y a 5 ans (au moins) que cela va devenir une innovation.

Promouvoir le web : en quoi est-ce un intérêt ? Je ne vois pas pourquoi il faudrait promouvoir les web app et le web en général. Ce n'est pas « le Bien » absolu.

Et pour l'instant, en quoi Firefox OS innove-t-il ? Je n'ai pas regardé la présentation en détail, mais pour l'instant, je n'ai rien vu qu'il n'existe déjà sur d'autres OS.

Je ne vois absolument pas le sous-entendu. Il dit simplement qu'une des applications les plus en vue doit être réécrite. Je trouve que ça sous-entend plutôt qu'elle était mauvaise…

Et donc Firefox n'aura aucun intérêt tangible par rapport aux autres OS mobiles qui vont probablement implémenter le standard.

Elle est phare parce qu'elle est très utilisée, tout simplement. J'imagine qu'à peu près tous ceux qui ont un compte Facebook et un iPhone (et ça en fait, du monde !) utilisent l'appli…