flan a écrit 1848 commentaires

Si je devais rebooter mon ordi à cause d'un simple navigateur, je m'inquiéterais au sujet de l'**OS**, personnellement.

À ma connaissance, il n'y avait pas vraiment de gestion de droits sur FAT32 (donc Windows95/98/Me ne peuvent pas avoir de distinction root/non-root), mais sur Windows 2000 puis XP (pfiou, ça fait déjà 12 ans), l'utilisateur n'est pas root (compte SYSTEM), il est simplement admin par défaut (et tout ne lui est pas accessible).

c'est sûr, il faut de la volonté pour changer ses habitudes.

J'ai dû pas mal me forcer (et m'y reprendre à trois reprises) pour utiliser un IDE (Pycharm) pour faire du Python à la place d'un VIM que j'utilise depuis 8 ans, avec une façon de travailler qui n'a plus rien à voir. Au final, j'y ai beaucoup gagné, mais ce n'était pas si facile.
Pareil pour passer à OS X (il y a 9 ans), j'ai dû me forcer à tout repenser (façon de ranger ses documents, utiliser les applications natives d'OS X alors que j'étais parti sur Firefox et Thunderbird, …) et utiliser les subtilités d'OS X, mais au final je pense avoir été gagnant.

Mais après, même en faisant des efforts, certains environnements ne plairont jamais à certaines personnes, on ne peut rien y faire.

Via F10 (Exposé), Pomme+Tab ou Ctrl+Flèches. C'est plutôt pas mal je trouve.

Dans ce cas, le mode plein-écran est fait pour toi.

Au final, le système est plutôt bien fichu. Il faut accepter que ça ne fonctionne pas comme sous Linux ou comme sous Windows, mais ce n'est pas pour autant que c'est moins bon… C'est simplement différent.

Chacun a ses propres projets majeurs, je pense ;)

Qu'est-ce qu'ils entendent exactement par gel de la Debian 8 ?

Est-ce que c'est les paquets intégrés qui sont choisis, ou les versions des paquets ? Par exemple, je vois Samba4.0 qui est actuellement dans Jessie, est-ce que ça sera toujours la 4.0 ou peut-on espérer une 4.1 voire une 4.2 ?

Malheureusement, il reste encore quelques paquets majeurs qui sont bloqués en Python 2 (je pense notamment à Paramiko, qui est une implémentation en Python du protocole SSH). Mais c'est vrai que la plupart (des projets majeurs) sont maintenant en Python 3.

Il faut vraiment abandonner Python 2, Python 3 corrige quelques énormes (à mes yeux) erreurs de conception de Python 2, comme le mélange de chaînes de caractères unicode et brutes qui était une source très commune de bugs.

Par expérience, tout ce qui utilise X11 sur OS X est à proscrire. Ça donne un mélange vraiment peu utilisable et très mal intégré… (sans compter que X11 est de plus en plus « difficile » à installer sur OS X : il était fourni par défaut il y a quelques années, puis en option, et maintenant il faut recompiler, de mémoire).

Il y a déjà un gvim pour Windows

un sous-forum du site 4chan.org, je crois (qui a la réputation d'être fréquenté par des gens un peu… particuliers)

Je n'ai pas spécialement eu de problèmes de perfs avec Python + Qt (PyQt et non PySide), en revanche j'ai eu (et j'ai toujours :( ) quelques rares problèmes de stabilité totalement aléatoire, notamment en utilisant des threads. Une bonne partie de ces problèmes ont été résolus en mettant à jour PyQt et Qt, mais il y en a toujours de temps en temps (et sans stacktrace, dans un produit un peu complexe, ce n'est pas évident de débugguer…).

(sinon, il parle peut-être de ctypes, qui permet d'utiliser des libs C en Python)

Personnellement, j'utilise des .fig et des .svg directement dans mes .tex, et cela permet d'utiliser du LaTeX (y compris les macro) dans les légendes. D'ailleurs, le HTML ne permet pas les macros, c'est éliminatoire pour moi.

Mouarf

La faille avait été introduite par un mainteneur Debian, mais elle aurait très bien pu être introduite par un mainteneur d'OpenSSL…

Heureusement que les failles détectées ont été corrigées !

Dur de savoir si ce sont des erreurs ou des erreurs « volontaires »… Quant à la backdoor d'OpenSSH dans ?BSD demandée par le FBI, je doute que ça soit une simple erreur.

« Juste une question de temps ». La faille dans Debian est restée 4 ans. Certes, c'est toujours une question de temps, mais ça reste énorme.

De toute façon, les codes des OS actuels sont trop énormes et évoluent trop vite pour espérer faire des audits de code, sans compter que même en ayant le code sous les yeux, on peut passer à côté (faudrait que je retrouve les infos sur une faille ajoutée en mettant & au lieu de && dans une ligne de code, je ne me souviens plus des détails).

Pourquoi seulement « privateurs » ?

Entre l'implémentation d'OpenSSH dans ?BSD et la génération de clef moisie dans Debian…

Thomas parle d'utiliser SSL pour faire uniquement du chiffrement, sans la couche d'authentification du serveur.
Je réponds que sans cette authentification, le chiffrement ne sert à rien (même si sur le fond, je suis d'accord avec lui). Il n'y a aucune notion de clef privée là-dedans.

Tu oublies un détail : si tu n'es pas capable d'assurer que tu parles à la bonne personne, alors tu n'es pas capable d'assurer que seule la bonne personne entend.

Ce n'est pas « actuellement », ni une question d'implémentation, c'est par définition. Si tu autorises les MITM (en refusant d'authentifier la personne), alors tu ne garantis pas que seul le destinataire lit ce que ton trafic.

Sois-tu sais que c'est une arnaque, et tu ne donnes pas du tout ton mot de passe, soit tu ne le sais pas, et ton système ne servira de toute façon à rien.
Avec ton système, tu dois pouvoir récupérer l'adresse IP de l'attaquant, autant dire pas grand-chose de valable pour beaucoup d'énergie…

Sans compter que les gens ont déjà du mal à se souvenir d'un mot de passe, alors s'ils doivent en plus se souvenir d'un mot de passe dont ils ne doivent pas se servir… (et qu'accessoirement, ça implique de développer les applications / sites web en double).

Non, avoir un design foireux n'est aucunement un argument pour ne pas divulguer la correspondance de Snowden. D'autant plus qu'ils pouvaient tout à fait rechiffrer avec une autre clef par la suite.

Je ne vois vraiment pas en quoi utiliser la même clef privée pour tous les utilisateurs peut être considéré comme une bonne idée.

Pour que ce genre de système fonctionne, il est nécessaire qu'il soit public, et donc que le service secret le connaisse.
Donc si tu t'en sers, il sera de notoriété publique que tu auras prévenu tout le monde de la mise en demeure. Il y a peu de chances que ça soit défendable devant un juge qui respectera l'esprit de la loi.

Il n'y a (presque) plus le choix pour systemd uniquement parce que les développeurs des équivalents (ainsi que les intégrateurs dans les distribs) ont abandonné les concurrents.

Tu as la possibilité de changer ça, simplement il faut mettre la main à la pâte pour que le boulot soit fait.

Ce n'est pas du tout pareil. Là, en gros, tu as 3-4 dépôts, et tu as soit accès à l'intégralité du dépôt, soit rien.

C'est plus compliqué de faire un dépôt APT qui s'adapte totalement à l'utilisateur : il faut générer plusieurs fichiers d'index par utilisateur, avec un sommaire contenant les md5/sha1 de ces fichiers d'index, puis signer ce dernier fichier. Bref, tout mettre en cache en permanence.

Neuf millions vendus en quelques jours, c'est plutôt pas mal.