flan a écrit 1830 commentaires

Ça pourrait être pas mal que l'USB-3.1 puisse faire du réseau. On aurait enfin une vraie prise universelle (vidéo, audio, alimentation, réseau, et périphériques classiques).

… pour être le meilleur choix, quelques soient les besoins de l'acheteur potentiel.

source ?

Outre Github, maintenant beaucoup d'outils ne proposent que git comme interface. Si je veux une forge à peu près moderne à installer chez soi, je ne vois que Gitlab qui soit à mon goût, et qui (Ô surprise) ne sait pas faire avec Mercurial. Si je ne me trompe pas, mon IDE sait uniquement faire du SVN et du Git par défaut (j'avoue que ça fait longtemps que je n'ai pas touché à la conf, donc je peux me tromper), même s'il y a un plugin pour Mercurial.

Même si je serais volontiers passé de svn à Mercurial, cette différence de traitement dans les outils a fait pencher la balance en faveur de git.

Les média ont un rôle dans l'éducation de la population ; on peut appeler ça propagande si tu préfères, mais quoiqu'il arrive, les programmes passant dans ces média ont forcément une influence.

En effet, Scala a un truc codé en Scala (SBT)… et j'aimerais bien qu'il soit codé dans un autre langage. Je pense de plus en plus à refaire quelque chose en Python pour mes propres besoins (je trouve qu'avoir 1 min de lancement pour quelques secondes de compilation est insupportable).

Sinon, on peut faire comme dans (presque) tous les autres langages : un dépôt central (avec la possibilité de rajouter des dépôts secondaires) qui contient les bibliothèques avec les différentes versions.
Je ne comprends pas le problème de la sécurité… au contraire, ça permet d'automatiser l'ensemble de la procédure (téléchargement, vérification de l'origine via une signature, vérification du téléchargement via un hash sha1).
Si on doit télécharger à la main sur des dizaines de sites différents, tu auras en pratique beaucoup moins de garantie.

Les environnements virtuels de Python sont pas mal, à ce niveau (je parle de Python, mais ça existe probablement dans d'autres langages).

C'est un peu la même idée qu'un chroot, mais limité à Python : la commande python correspondra à la version de Python choisie pour l'environnement virtuel en cours, et seuls les modules de l'environnement virtuel seront visibles.
Tu peux donc facilement passer d'un venv à l'autre, en choisissant la version de Python et des bibliothèques. Très pratique pour tester !

pourquoi installer dans /usr/local ? Tu pourrais installer dans ~/.local , qui ne demande pas des droits root.

À ce que j'ai entendu (par des gens dans le milieu du CHP), certains s'attendent à ce que l'ARM puisse concurrencer le x86 dans 5 ans environ (s'il n'y a pas de grosse surprise). Mais naturellement, si l'ARM obtient les mêmes perfs que le x86, ça sera au détriment de la consommation (qui sera équivalente à celle du x86).
Après, il n'y a pas de mystère : ce sont (globalement) les mêmes technos, qui veulent répondre aux mêmes problèmes, donc on peut s'attendre à avoir des résultats équivalents (sachant que finalement, la surcouche historique due au x86 n'est pas si coûteuse).

L'intérêt de l'ARM reste quand même d'avoir un vrai concurrent à Intel : depuis qu'Intel est le seul « vrai » fournisseur dans le CHP, le prix des processeurs a bien augmenté.

Accessoirement, on peut faire de l'OCSP via HTTP.

En quoi est-ce du code volé ?

Ok, merci pour toutes ces infos ; ça commence à être plus clair comme ça.

Et go a l'air de te poser beaucoup de problèmes niveau sécu. J'imagine que c'est lié au besoin des dernières versions de chaque lib (je comprends le risque à utiliser le git directement) et à la compilation en statique, mais y a-t-il autre chose ?

Merci :)

Et encore, docker est pas si problématique, car il suffit de voir kubernetes ou openshift origin ( qui embarque etcd et kubernetes ) pour se dire que ça va être assez vite relou quand un souci va arriver. Et il faut aussi rajouter les trucs comme flannel, les autres bouts de docker, etc, pour avoir un truc qui va servir à la prod.

Qu'est-ce donc que kubernetes ou openshift origin ?

Il y a un risque : tu perds le mot de passe ou la clef et tes données sont irrécupérables. En entreprise, tu perds la personne (et donc son mot de passe) et ses données sont irrécupérables (sauf si tu as fait les choses bien, avec des clefs de recouvrement).

MS peut vouloir suivre le modèle de Google ou d'Apple: avant ils vendaient des logiciels, maintenant ils veulent donner un logiciel pour vendre autre chose avec. Apple donne OS X pour vendre leur matériel, Google donne Chrome/ChromeOS/Android pour que les gens utilisent gmail/google/maps pour vendre de la pub, et MS pourrait donner Windows pour vendre du service (Office 365, Azure, leur drive).

Pour les salaires, il n'y a pas de problème, et au-delà de ça, il est spécialiste dans un domaine où les experts sont rares et chers (et il peut trouver un boulot intéressant dans la journée si son CDD n'est pas renouvelé).
Mais la banque s'est arrêtée à « CDD ».

Une grosse réticence des banquiers, même, et c'est de pire en pire.
J'ai eu l'exemple d'un couple qui a pu prendre un emprunt il y a environ 10 ans (avec un petit CDD de doctorant et l'autre étudiant), et qui n'a pas pu prendre un emprunt l'an dernier (ils étaient devenu ingénieur R&D en CDD pour l'État et médecin, bref pas les métiers les plus risqués au monde).

Ah  ? Je ne me souviens pas qu'on m'ait demandé mes clefs de chiffrement.

Bin non. Si tu as le droit de garder les choses secrètes, tu ne donnes pas la clef, et voilà tout ; pas besoin d'avoir à prétendre que les données n'existent pas. Et si c'est illégal, coopérer avec la justice me semble assez raisonnable, non ?

Chez moi, tous les disques sont chiffrés, tous mes services sont en SSL et j'ai ma propre CA, mais si la police me demande de casser ce chiffrement, je donnerai les clefs sans souci (s'ils en ont le droit, évidemment), je ne chercherai pas à discuter…

N'est-ce pas un peu sexiste de différencier comme ça les hommes et les femmes ?

Il y a une différence entre Windows/OS X et Linux.
Sous Linux, tous les paquets ont le même statut, même si certains sont plus utilisés que d'autre. openssl est une dépendance au même titre que n'importe quelle lib obscure.
Windows et OS X arrivent avec une pile logicielle conséquente, et font le pari que finalement, tu n'auras pas beaucoup de bibliothèques en double (si le code était vraiment commun, il serait dans l'OS de base).

Avec Salt, tu as un unique serveur maître qui va jouer l'intermédiaire, et qui a une configuration globale.
Dès que tu vas demander quelque chose, tu vas passer par ce maître (et tu n'as pas besoin d'avoir le droit de connexion directe aux serveurs).

Avec Ansible, n'importe quel admin sys va se connecter directement aux machines qui sont définies dans le fichier de conf' spécifique au projet, sans passer par un intermédiaire.

Oui, bien sûr qu'on peut trouver des contre-exemples.
Par contre, je ne suis pas sûr que la faute soit vraiment toujours du côté de Windows : beaucoup de logiciels n'ont pas spécialement été bien codés, et Windows qui était bien trop laxiste permettait beaucoup d'horreurs qui ont été progressivement interdites ; je pense par exemple à certains jeux qui stockaient les données du joueur dans le dossier d'installation (une hérésie pour un Unixien, dès les années 70 !).
Les modes de compatibilité consistent d'ailleurs souvent à reproduire le comportement de certains bugs de Windows sur lesquels comptent des logiciels mal codés.

Tu peux même aller plus loin : j'ai installé ce week-end Starcraft, qui est sorti en 1998, et qui fonctionne toujours aussi bien sur Windows 10, 17 ans plus tard.