flan a écrit 1830 commentaires

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.

Tu as rarement le choix quand tu passes par un hébergeur avec du mutualisé. C'est quand même une grosse contrainte.

Merci pour ces retours.

Malheureusement, git est un prérequis. Pour la difficulté d'installation, finalement je ne suis pas trop exigeant vu que celle de Gitlab s'est bien passée (il y a à peine eu besoin de recompiler Ruby) même si elle est un peu longue. Par contre, je n'ai pas réussi à mettre du SSO et je reste bloqué avec du login/mot de passe classique.

Pour chez moi, j'aimerais bien pouvoir me passer complètement de mots de passe (et tout faire en SSO à la place), mais pour le coup les IDE (intellij/pycharm) ne sont pas d'accord avec moi.

Pour moi, Redmine (que j'utilise déjà par ailleurs) est quand même nettement moins puissant qu'un Github (Gitlab ?), sachant qu'en plus, on peut intégrer Redmine dans Gitlab.

Je n'ai pas installé de Redmine, mais Gitlab est également basé sur du RoR et je n'ai pas trouvé ça trop chaud à installer (après, je suis assez habitué à configurer du reverse proxy apache, ça vient peut-être de là).

Pour les clefs SSH de git, à vrai dire, j'aurais préféré faire du git over SSH pour profiter de l'authentification via Apache, mais je ne me suis pas encore trop penché sur la question.

Quand j'installe un service web chez moi, j'aime bien que l'authentification soit gérée par le serveur web (apache ou nginx) et non par l'application.
Ça me permet d'utiliser ce que je veux pour l'authentification, en évitant les bêtes mots de passe.
est-ce faisable pour seafile ?

J'ai l'impression que oui, vu que ça me semble basé sur Django, mais j'aurais aimé être sûr :)

C'est en effet la méthode classique, quitte à mettre un petit mot en commentaire.

Je l'ai fait avec plusieurs projets en Python, ça s'est toujours bien passé.

J'ai l'impression que chacun a son petit paquet Python qui empêche sa transition à la 3.

Personnellement, quasiment toutes celles que j'utilise sont passées à Python 3, et j'arrive à faire mes nouveaux projets perso en Python 3.3. Ça fait du bien, faut bien le dire.

Oui, je sais que c'est une histoire de GTK et KDE, vu ce que j'ai dû installer pour faire fonctionner l'ensemble correctement.

Mais il n'en demeure pas moins que si tu te contentes de l'archive de Firefox, ça ne fonctionne pas de façon nominale. On verra bien ce que ça donne avec Australis, évidemment.

Je l'ai fait, et ce n'est pas réellement suffisant vu que le Firefox obtenu peut être assez moche (surtout si on utilise KDE).

Je suis souvent tombé sur du code libre vraiment pourri ou sans aucune documentation et ce, même sur de gros projets (genre Hadoop il y a quelques années, maintenant je regarde un peu moins le code), quasiment toutes les fonctions avaient TBD (To Be Documented) comme seule doc…
Par contre, je suis aussi souvent tombé sur du code libre plutôt bien fichu. Là où ça pêche quand même pas mal, c'est la doc, même si le code en soi est propre. Mais ça se comprend, le temps est limité pour tout le monde, et c'est dur de demander de multiplier par deux (voire davantage) le temps de développement juste pour ajouter une doc qui a de fortes chances de ne servir à rien.

En entreprise, ça va dépendre de plein de choses : si la boîte a une culture de qualité (et qu'elle a compris l'intérêt de faire un code propre), si les développeurs sont suffisamment geeks pour aimer le code propre, etc.
J'ai pas mal d'échos dans un sens comme dans l'autre ; bon, ok, pour le code pondu par la majeure partie des SSII, les échos vont tous dans le même sens :D

Je vote pour Python 3 également. Après, on peut se contenter de Python 3.3, voire 3.2 (seule version 3 dispo sur Debian Wheezy, par exemple).

Personnellement, je ne peux qu'encourager de passer par un ORM (SQLAlchemy).

Ça demande un investissement un peu plus grand au début, mais ça se révèle en général un gain de temps très important sur le reste : tu vas plus vite pour coder tes requêtes, la gestion des connexions va se faire de façon transparente, et surtout tu pourras passer d'un moteur à l'autre sans souci. Accessoirement, ça permet de rejeter la sécurité sur l'ORM, sachant qu'il s'en occupera de toute façon bien mieux que toi (sauf si tu es spécialiste du sujet).

Je parlais de ReactOS qui en est à ajouter le support de l'USB.

(cela dit, le support correct de l'USB est bien plus récent, me semble-t-il)

Ils en sont à ajouter le support de l'USB… Autant dire qu'il ne sera pas utilisable en prod avant quelques années, quand les gens auront choisi de rester définitivement sous XP ou de passer à un OS plus moderne (Windows ou autre).

C'est un peu facile de toujours se reposer sur « c'est installé par défaut, ce n'est pas de notre faute ».

Pour les logiciels, Firefox avait réussi à bien décoller (30% du marché) alors qu'IE était installé par défaut, maintenant Chrome est passé devant et IE se retrouve derrière.

Et même sur les OS, de mémoire, aux États-Unis, Mac OS X était en gros à 2% en 2003 et est maintenant à 10% (ordis de bureau uniquement). Comme quoi, c'est possible de faire changer les habitudes.

Bof. Apple a réussi à bien reprendre pied sur le marché, sans même être compatible Windows (ça n'a été le cas qu'en 2006 de mémoire, avec Bootcamp).

Évidemment, c'est mieux d'être root. Mais ce n'est pas critique pour faire tout ce dont tu parles.

2) l'impact d'un virus sur le système (ne corrompt que le profile de l'utilisateur, pas le système)

La formulation est curieuse : ça ne corrompt que ce qu'il y a de plus important, et ça ne touche pas à ce dont on se moque.
Pour un ordi perso, le profil de l'utilisateur est la seule chose d'importance, le reste on s'en moque (la donne est différente pour un serveur, évidemment).

Tiens, aurais-tu un lien avec des exemples de code source de la pile graphique d'iOS ? Ou balances-tu ça complètement au hasard ?

Sinon, la bonne raison est que tout simplement un flat design n'empêche pas d'utiliser des effets graphiques un peu complexes, comme un flou gaussien (très gourmand alors que cela semble tout bête).