flan a écrit 1830 commentaires

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 :)

J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?

Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).

• HTTP permet plein de choses en matière de proxy ou d'authentification
• j'aime bien que SSH ne serve qu'à l'administration (donc ouvert uniquement à un sous-réseau dédié), en ouvrant un serveur HTTP (qui tourne avec un simple utilisateur) pour les services.

Enfin, peut-être que je me trompe complètement :)

Qui sont les experts militaires qui étaient contre ?

J'avais vu que le nombre de morts avait globalement diminué dans les mêmes proportions dans tous les pays, ce qui aurait tendance à éliminer les facteurs géographiques comme l'alcool, les contrôles ou les limitations diverses et variées, renforçant l'argument de l'amélioration des voitures. Mais bon, je n'ai plus la source (c'était il y a 5 ou 10 ans…)

Alors je veux bien croire que dans ce contexte, un casque de vélo ne fait pas trop le poids face à un 4x4 de 1.5 tonnes lance a 70. Ça veut pas dire que le casque ne te servira pas dans un contexte un peu moins vélo-hostile.

Bien sûr qu'on trouvera toujours des cas où le casque sera utile. Maintenant, rendre le casque obligatoire est une certaine dépense d'énergie, énergie dont l'utilité doit être optimisée au maximum.
Il faut donc se demander si :

• le nombre de vies sauvées (morts ou accidents graves) est important (si la plupart des accidents ont lieu contre un 4x4, comme tu dis, l'intérêt du casque est négligeable),
• d'autres mesures plus efficaces ne pourraient pas être mises en œuvre à la place (pour consommer différemment cette énergie),
• s'il est pertinent de n'appliquer le casque qu'aux cyclistes (après tout, les traumas crâniens existent également chez les automobilistes et les piétons).

Que ce sont des revenus générés par des iPhone mais pas par Apple ?

En effet, il y a un mot-clef important : numpy, qui est une bibliothèque de calcul scientifique pour Python, mais qui sous le capot utilise du C.

Du coup, quand on utilise numpy au mieux de ses capacités, le code Python ne sert que de ciment à des appels de code C ; tout le boulot est fait par du C optimisé.

Merci pour le message !

Fait : Les SSD sont infiniment moins gênées par des données non-séquentielles, car ils ne sont pas des disques durs. Ce qui rend la défragmentation inutile.

Ton implication est fausse. La défragmentation est donc moins utile. Tout est de savoir dans quelle mesure !

Fait : Le support de stockage utilisé par les SSD ont un nombre limité d'écritures avant d'être kapout. Ce qui rend la défragmentation dangereuse.

Ton implication est encore fausse : pour ça, il faudrait savoir de combien elle réduit la durée de vie du SSD. Si c'est de 0,001%, on peut la considérer comme indolore.

Fait : Un contrôleur SSD essaie de gérer la durée de vie ses blocs de manière uniforme. Pour éviter que certains deviennent kapout alors que d'autres étaient "comme neufs". Donc évidemment, les données vont être fragmentées.

Ton implication est encore fausse. La fragmentation du SSD n'a pas lieu au même niveau.

De la même façon que beaucoup d'ouvriers ont perdu leur travail avec l'apparition des moissonneuses batteuses

Sur quoi te bases-tu pour dire qu'ils l'ont toujours fait, surtout vis-à-vis de PDG de boîtes aussi énormes ?