flan a écrit 1865 commentaires

Accessoirement, il y a plein de contraintes qui rendent la chose beaucoup moins sexy :
- hors de question d'avoir la moindre confiance dans l'hébergement chez n'importe qui : dans le meilleur des cas, les données sont publiques et on peut se contenter de refaire plein de fois le même calcul (et on prend le résultat de la majorité, mais là il n'y a rien de neuf vu que SETI@home fait ça depuis 20 ans au moins), dans le pire des cas, … bah on ne veut surtout pas que les données soient en clair, et c'est rare de pouvoir travailler sur des données chiffrées : que fait-on dans ce cas-là ?
- les data-center, en plus d'apporter plein de puissance de calcul ont d'autres qualités, notamment la bande-passante et la latence : je ne suis pas sûr que ça puisse être remplacé facilement.

À vue de nez (après 15 secondes d'analyse du setup.py), il te suffit de créer un compte sur https://pypi.python.org , puis dans le dossier des sources de faire

python3 setup.py register
python3 setup.py sdist upload


Accessoirement, il n'y a même pas de renouvellement (donc aucune requête) quand le certificat est encore largement valide (plus de 10 jours, je crois).

Quake 3 a pas loin de 20 ans, il n'a strictement aucune chance d'utiliser toutes les ressources du matériel (c'est-à-dire utiliser les nouvelles fonctionnalités et pas seulement les instructions graphiques qui ont 20 ans).
En libre, je ne suis pas sûr du tout que ça existe de façon générale.

Juste par curiosité, pourquoi avoir pris une RX580, du coup ?

Tient, un truc bête : ne pas mettre du Windows dans les sous-marins nucléaires (ni sur les portes-avions, ni dans les ministères, etc) à cause des problèmes d'espionnage et de potentiel contrôle à distance. C'est tellement basique, mais non je pense que personne ne leur a téléphoné pour leur dire, je ne vois que ça comme explication.

Ou alors qu'ils ont bien pris le problème de l'espionnage et du potentiel contrôle à distance en compte, et que ça n'empêche pas d'utiliser du Windows.

Si :

qui possède […] 4 maisons et 1 appartement

(maisons et appartements sont des immeubles, comme le confirmera n'importe quel notaire).

dire que NH possède 5 immeubles est un peu simpliste, voire faux : un seul est détenu à 100%, les autres étant à 50, 25, 12 et 12%…

je cherche toujours un aspect positif de la chose…

La décentralisation du contrôle de la monnaie.

Et en quoi est-ce positif ? Le contrôle de la monnaie est un outil extrêmement utile à un état pour orienter son économie et adapter son taux de change vis-à-vis des économies des pays voisins. Ton assertion un peu péremptoire mériterait d'être un peu argumentée :)

J'ai l'impression que l'apport de Gufo se situe essentiellement au niveau de la syntaxe.
Il y a certainement beaucoup de progrès à faire, mais n'y a-t-il pas d'autres axes d'amélioration ?

Quelques idées en vrac :

• doit-on garder toujours uniquement stdin, stdout et stderr ? Pourquoi pas avoir plusieurs entrées (exemple tout bête mysql < monfichier.sql << mon-mot-de-passe) et davantage de moyens de sortie ?
• comme déjà dit plus haut, PowerShell (avec sa manipulation d'objets) permet de se passer de awk/sed/… qui ne sont pas très tolérants aux erreurs, est-ce que cela a été envisagé ?
• pourquoi ne pas intégrer un véritable affichage graphique (un ls affichant des icônes, au hasard, ou des tooltips qui s'affichent dynamiquement au-dessus de chaque argument ou commande) ?
• comment améliorer l'intégration de la souris dans l'écriture de commandes ?
• comment améliorer l'intégration des programmes externes (bash-completion est plus un hack qu'autre chose) ? on pourrait imaginer qu'un programme externe amène sa propre autocomplétion, une aide plus intelligente, une vérification de type avec les commandes suivantes, …
• pourquoi ne pas tenter quelque chose de totalement différent (par exemple, Automator d'Apple partage beaucoup de points communs avec un shell, pourrait-on envisager quelque chose qui s'inspire des deux ?)

Bien sûr, il y a potentiellement de gros problèmes de perf à prendre en compte et plein de mauvaises idées là-dedans, et plein d'autres bonnes idées à avoir.

Oui, la situation était différente il y a 50 ans.

Ce n'est pas la faute de Boeing si l'A400M n'est pas capable de remplir les missions pour lesquelles il a été conçu.
Bon, c'est un peu aussi la faute des états, notamment l'Allemagne qui a obligé à utiliser des industriels allemands incompétents (sans méchanceté : ce n'était pas leur domaine) plutôt que des industriels français compétents.

L'économie est une science. Malheureusement, beaucoup de gens confondent « jouer avec des chiffres » et « faire de la science ».
Ce n'est pas parce que tu as claqué des chiffres en face de colonnes avant de mouliner tout ça un bon coup que c'est scientifique, ni même que ça a une quelconque valeur.

Un raisonnement peut être scientifique même sans s'appuyer sur des choses quantifiables. En revanche, les raisonnements quantifiables que l'on voit fréquemment n'ont rien de scientifiques. Des hypothèses sont prises pour des certitudes, des conditions sont oubliées, les remises en cause sont inexistantes, etc.

1) simple : ils vivent sur leurs acquis. Les projets les plus récents ont quand même une forte tendance à se planter magistralement (coucou l'A400M) et à perdre de vue les objects réels.
Mais bien évidemment, ça ne fonctionne qu'un temps…

C'est-à-dire  ? Le contrat dit-il clairement que tu peux t'en servir comme plate-forme téléphonique ?

et que dit le contrat ?

1. pour dégager complètement la GPL de macOS (c'est par exemple pour cette raison qu'ils ont poussé CLang, afin de virer GCC sous GPL)

Merci pour l'info, ça a l'air intéressant mais encore un peu jeune :( Dans mon cas, il manquerait au moins l'authentification HTTP et le packaging en .deb, mais je garde sous le coude.

tu peux faire du XMPP via HTTP(S) (cela s'appelle BOSH)

Oui, c'est vrai, en théorie…

En pratique, cela se matérialise par deux processus qui n'ont rien à voir.

Tu déplaces ton fichier de dossier en sous-dossier, et en toute logique tu vas du plus général au plus précis (si tu as une arborescence du type ~/Documents/Administration/Impôts/2017/Revenus/, par exemple. Et tu ne fais ça qu'une fois ! De plus, quand tu fouilles, cette même arborescence aide beaucoup. Si l'arborescence que je consulte est du type ~/Documents/Administration/Finances/Revenus/2017 , je mettrai exactement le même temps pour trouver mon document.

Avec des tags, je vais devoir taper successivement "documents", "administration", "impôts", "revenus" et "2017", mais il faut aussi que je me souvienne quels tags j'ai mis sur tous les autres documents du même type. Est-ce que j'ai mis "revenus" sur l'année dernière ? ai-je mis "taxes", "dgfip", "IR" ?
Et que faire quand je veux fouiller un peu dans mes documents ? Je liste les tags un par un ? je vais revoir 50 fois les mêmes documents (et ça va exploser avec le tag 2017 ou 2016).
J'ai une liste numérique de tous mes bouquins physiques, qui permet notamment de spécifier le genre littéraire du livre (les infos sont récupérées d'entre autres Amazon, mais le genre est souvent fantaisiste), qui fonctionne par tags. Au final, quand j'ajoute un nouveau livre d'un auteur dont j'ai déjà d'autres livres, je suis obligé, systématiquement, d'aller vérifier quel genre j'ai attribué aux précédents pour avoir quelque chose de cohérent.

Bref, je ne crois vraiment pas aux tags comme unique système de tri, même si ça peut être utile quand c'est déterminé de façon automatique (par exemple en fonction du contenu ou des méta-données — ça fonctionne très bien avec les mp3) et constante (pas de synonyme), ou au moins par vague (appliquer le tag à plein de fichiers d'un coup).

Avec le RAID 6, tu perds 2 disques (en termes d'espace utilisable) sur le total.
Avec le RAID 10, tu perds la moitié des disques.

Bref, dès que tu as plus de 4 disques, le RAID 6 est plus rentable.

Y a-t-il un engagement contractuel sur l'IP fixe chez BT ?
Il me semble que l'IP est fixe en pratique, mais qu'il n'y a aucun engagement de leur part à ce niveau.

J'ai l'impression que je me suis mal exprimé sur Kerberos/GSSAPI ; c'est du SSO qui n'a rien à voir avec HTTP (enfin, autant que le concept de login/mot de passe).
Quand je me connecte à ma session (Windows/Linux/macOS), que ce soit par carte à puce/Yubikey ou avec un mot de passe, mon ordinateur envoie tout ça au serveur Kerberos de mon employeur qui lui renvoie en échange un ticket valable une journée (on peut également obtenir un ticket n'importe quand avec kinit, après s'être connecté en local sur la session). L'ordinateur ouvre alors la session et garde le ticket pour lui. Ensuite, quand je me connecte à un service quelconque (serveur web, mail, NFS, SSH, imprimante, Jabber, …), mon ordinateur va transmettre le ticket au service qui me reconnaîtra automatiquement, sans que j'ai besoin de rentrer le moindre login ou mot de passe. Bon, en vrai, c'est un chouia plus compliqué, mais ça reste vrai dans les grandes lignes.
Du coup, il n'y a aucun hack à utiliser une authentification Kerberos sur HTTP ou sur SSH (en cherchant des cookies dans le navigateur).

• mais si tu respectes certaines bonnes pratiques, ton réseau d'administration est différent de ton réseau de développement, donc ton port 22 n'est pas accessible aux développeurs. Au contraire, 443 a de fortes chances d'être accessible sur le réseau des utilisateurs.

• je ne comprends vraiment pas ce que tu veux dire ; en quoi utiliser une clef sans mot de passe est proche de ce que fait HTTPS ? Le fonctionnement de ces deux protocoles est fondamentalement différent :

  • HTTPS permet l'authentification du serveur très facilement, SSH ne permet que de savoir si tu te connectes toujours au même serveur (sauf si tu mets l'empreinte de sa clef publique dans le DNS, mais ça commence à être compliqué à faire, sans garantie que le client la prenne en compte).
  • HTTPS permet les connexions anonymes, pas SSH (qui force l'authentification mutuelle)

• oui, mais dans ce cas, soit tu acceptes de remplacer du code éprouvé (OpenSSH) par du code très jeune pour l'administration, soit tu as deux services SSH qui tournent sur la même machine (cette option étant de toute façon obligatoire si tu respectes la séparation entre réseau d'administration et réseau de dév.).

• je ne vois pas pourquoi tu parles de cookies HTTP, et en quoi ils sont un hack. En tout cas, quand tu fais du git+http, tu n'as absolument pas besoin de cookies…

Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP… qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.

Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.

Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)

• je ne connais pas bien le cloud, mais je n'ai jamais eu de problème à installer un git avec authentification Kerberos en HTTP (y compris en bidouillant gitlab pour le faire sur la version open-source) sur des machines à ma disposition. Ensuite, même si SSH permet de faire plein de choses, je ne suis pas sûr qu'il soit aussi souple que HTTP (ce n'est pas un reproche, ils n'ont pas été conçu pour faire la même chose) :

  • plein de serveurs HTTP existent pour faire des proxy (reverse ou forward)
  • pas besoin d'ouvrir de nouveaux ports si le 443 est déjà ouvert (j'aime bien limiter les ports ouverts)
  • on peut faire des accès sans authentification (sauf si on fait de l'authentification SSL mutuelle, certes), quelque soit le serveur
  • on peut mettre un certificat SSL sur le serveur (pour être sûr de s'adresser au bon serveur dès la première connexion) — ok, si on a la main sur le DNS, on peut également faire ou un LDAP, ça peut être jouable en SSH… mais c'est bien plus complexe
  • on peut faire des virtualhost (donc plusieurs sites qui n'ont rien à voir entre eux sur le même serveur)
  • des milliards de plugins d'authentification sont déjà codés, avec notamment la capacité de bien dissocier la phase d'autorisation et celle de l'authentification (je m'authentifie en Kerberos, mais c'est un serveur LDAP qui m'attribue les droits)
  • OpenSSH n'est pas franchement pensé pour avoir plusieurs serveurs simultanés (ne serait-ce qu'un tournant root et l'autre avec un utilisateur standard), ce qui est requis pour éviter d'exposer un service root aux utilisateurs
  • cURL est là pour faire des requêtes en lecture

• Je connais essentiellement Kerberos comme authentification (c'est du du SSO), et git sait s'en servir de façon transparente en HTTP (le serveur lui réclame du Kerberos, le client se contente de lui en fournir). J'ai également une Yubikey, mais elle me permet de récupérer mon ticket Kerberos au login, du coup je ne sais pas si on peut faire de l'authent' SSL avec git de façon simple.
  En termes d'interface, je ne vois pas trop en quoi ça serait différent par rapport au SSH. cURL propose plein d'authentifications, si tu veux regarder :)