flan a écrit 1848 commentaires

Tu déformes quand même beaucoup le contenu de l'article.

On passe de « certains matériels vendus à des personnes (morales ou non) bien particulières sont piégés » à « (tous) les routeurs Cisco embarquent un mouchard ».
Le premier ne me choque pas du tout sur le concept (ça n'a a priori rien d'une surveillance massive), alors que le deuxième est bien plus dérangeant.

Oui et non.
Oui, parce qu'en effet, tu peux demander à l'utilisateur d'entrer son mot de passe et le valider via un script (ou via PAM).

Non, parce que le but de Kerberos est (entre autres) de ne pas avoir à fournir de mot de passe en permanence (l'autre but étant que ton mot de passe ne circule pas — tu peux donc t'authentifier même sur un réseau en clair). L'idéal étant de ne pas en avoir du tout, par exemple avec un certificat + clef privée stockés sur une carte à puce qui te permettent d'obtenir un ticket Kerberos (sachant que la clef privée ne quitte à aucun moment la carte à puce), et à partir de là, tu t'authentifies sur tous les services de façon transparente.

J'avais regardé il y a quelques temps différents serveurs XMPP, et Prosody est apparu comme nettement au-dessus du lot. La doc est claire, il est facile à installer, il fait « propre », les erreurs sont claires et explicites, il y a beaucoup d'options et de possibilités. Rien à voir avec ejabberd.
Le seul reproche que je lui fais est l'absence de gestion de Kerberos pour l'authentification.

Évidemment, dans la mesure où SQLite est un fichier, on peut tout faire à base de fichiers. Mais s'il s'agit de rester simple, je pense qu'une base devient rapidement une meilleure solution. Après, effectivement, une solution à base de fichiers plats peut tout à fait être la meilleure solution. Simplement, j'aime bien titiller pour avoir tous les arguments et mieux connaître les avantages et inconvénients de chaque solution. En l'occurrence, je n'ai pas bien saisi les inconvénients de la version SQLite…

Je me suis d'ailleurs fait un wiki basé sur des fichiers plats, vu que ça me permettait de garder facilement le contenu wiki dans du SVN (et donc de faire facilement de l'édition sur mon ordi pour que ça soit répercuté sur le wiki). Bon, ok, maintenant je m'installerais tout bêtement un Gitlab et je passerais à git ^{^}

Ça doit venir de ma mauvaise expérience : à chaque fois, je me dis que je vais faire un petit truc tout simple avec peu de fonctions, et au final je rajoute les fonctions peu à peu. Par exemple, une base SQL permettrait de faire facilement une suppression de commentaires (spam…), compter le nombre de commentaires et d'articles, faire un flux RSS avec les commentaires et les articles, etc…
Faire du fichier te bloque pas mal à ce niveau-là, alors que faire du SQL ne te ferme pas de porte (même si c'est très légèrement plus lourd).

On parle de Python, donc on a sqlite embarqué par défaut (sauf si on a compilé Python bizarrement).

Autant je peux comprendre qu'on ne veuille pas de dépendances à compiler (comme le connecteur MySQL le plus classique), autant j'ai un peu plus de mal à comprendre l'intérêt de faire une croix sur les dépendances en Python pur par principe. Y a-t-il un vrai gain de perf au moins ?

Bin justement, j'ai lu beaucoup de choses sur les données stockées chez les entreprises, mais pas grand-chose sur les logiciels eux-mêmes.

À ce que j'ai compris, le bug en question ne concerne pas le S/MIME, mais plutôt le stockage en local qui est censé chiffrer toutes les données personnelles du téléphone (que le mail ait été envoyé en clair ou non). Les pièces jointes envoyées en S/MIME sont chiffrées (sinon, elles ne pourraient pas être décodées à l'arrivée, je crois). D'ailleurs, il y a de fortes chances que les mails envoyés en S/MIME soient stockés chiffrés (sinon, ça perd beaucoup de son intérêt).

Qu'on veuille un logiciel libre par principe comme PolePosition, ça, je peux le comprendre tout à fait.

En revanche, je n'ai vu aucune preuve comme quoi les mails chiffrés sur iOS était accessibles à « certaines agences gouvernementales ». Aurais-tu un lien précis, ou ne te bases-tu sur rien ?

Pourquoi faut-il un client libre pour chiffrer ? iOS supporte par défaut le chiffrement S/MIME sans aucun problème, il suffit d'avoir un certificat + clef (.p12) correct installé sur le téléphone.

Tu peux maintenant faire du noSQL, au moins avec LDAP, Neo4j et MongoDB.

L'ORM de Django s'est quand même beaucoup amélioré avec les dernières versions. Cela dit, je ne connais pas spécialement SQLAlchemy. Mais pour ma culture personnelle, qu'est-ce qui est possible sur SQLAlchemy et qui ne l'est pas avec Django ?

Est-ce vraiment si bien que ça de devoir choisir un ORM, un moteur de template, un système d'authentification, … ?

Je dois avoir une vision déformée par l'abus de Django, mais j'ai du mal à croire que ça soit si pratique que ça au quotidien.
Après, ok, on peut faire un site en un seul fichier, mais à nouveau, je ne suis pas convaincu de l'utilité. De toute façon, il faudra bien ajouter un ORM, des templates, une couche d'authentification, …

Quand je démarre un site Django, j'ai un générateur pour me faire la structure du code (avec la conf pour la base de données, le système d'authentification, …), et j'ai un truc immédiatement fonctionnel avec un découpage logique et surtout toujours standard, ce qui rend les choses bien plus faciles pour se plonger dans un code externe.

Windows Mobile n'a rien à voir avec Windows Phone (à part le nom).

Et même si une partie ne veut pas de Windows, elle est suffisamment faible pour que ça ne pose pas de problème. Seuls 5% ont OS X, et ça n'a pas empêché Apple de proposer une logithèque conséquente sur iOS.

Bah Canonical a quand même un OS qui n'est pas encore accessible au grand public à offrir, c'est tellement mieux qu'un OS qui a déjà un certain succès !

(certes bien moindre qu'iOS ou Android, mais il se défend pas trop mal quand même)

Oui, il y a de ça aussi, en effet.

Ça ne concerne pas rpm ou deb, ça.
La façon de noter les dépendances est identique dans les deux types de paquet (paquet, et critères sur la version).

C'est lié à yum, aptitude, apt, … D'ailleurs, apt et aptitude n'ont pas exactement la même méthode de gestion des dépendances, ce qui fait que certaines opérations sont faisables avec l'un mais pas avec l'autre quand il y a des soucis de dépendance.

Un .deb, c'est une archive .ar qui contient un .tar.gz pour les métadonnées (infos sur le paquet à installer sous forme texte, plus les scripts d'installation et suppression) et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

Un .rpm, c'est une archive .cpio qui contient (de mémoire) une archive pour les métadonnées (infos sur le paquet à installer sous forme XML, plus les scripts d'installation et de suppression), et un .tar.gz qui contient l'arborescence complète des fichiers à écrire.

Qu'est-ce qui fait la différence pour la difficulté à mettre à jour avec du .rpm ?

Je suis bien conscient des limites du HTTP pour les perfs (d'où ma dernière phrase). Simplement, il ne faut pas en oublier tous les avantages que le HTTP apporte. De temps en temps, c'est bien plus rentable de faire du HTTP que de mettre en place un nouveau protocole ad-hoc qui n'aura pas la moitié de ses fonctionnalités (qui peuvent parfois bien débloquer une situation).

Tout passer par du HTTP a pas mal d'avantages quand on a une infra un peu compliquée :
* proxy
* reverse proxy
* possibilité de faire du MITM
* beaucoup d'authentifications possibles (login+mot de passe, mais aussi certificat SSL, kerberos, … sans compter Shibboleth et Webauth)

Après, pour les perfs, c'est autre chose.

Une autre des conditions est que le vote puisse se faire sans pression, il faut donc garantir que personne n'est derrière ton dos lors du vote.
Du coup, ça oblige à voter de façon publique, hors de chez soi.

Ça dépend énormément des sites. Linuxfr ne requiert pas grand-chose. Par contre, pas mal de sites font du JS à fond, mais mal : sans jamais libérer la mémoire et avec des anti-optimisations. C'est classique, notamment avec des pages à défilement continu (plus tu descends, plus tu as des images ou des articles qui s'affichent, mais le haut ne s'efface jamais)

J'ai eu la même réaction.
À vrai dire, je bosse (lentement, certes) sur un projet relativement similaire pour chez moi.
Mais je ne suis pas parti dans la même direction. Je génère la configuration complète du réseau local (je pars sur au moins un serveur et plusieurs machines clientes), ainsi que les certificats liés.
Ensuite, tout se fait via un script Python+Fabrics, pour lancer un serveur DHCP/BootP/TFTPD (qui permet d'installer automatiquement les OS) et ensuite installer les différents services.

Le problème avec sqlite avec du multiprocessus n'est pas lié à la haute dispo ; La base sqlite étant un simple fichier, elle a du mal quand plusieurs processus veulent y accéder en écriture.

J'avais déjà eu ce genre de faille il y a 2 ou 3 ans, sur une Ubuntu stable. L'écran de verrouillage plantait (mais pas immédiatement, genre au moins 5 ou 10 min après le verrouillage), et laissait la session complètement ouverte.