🚲 Tanguy Ortolo a écrit 12224 commentaires

Lapin compris. :'-(

Complet, pas plein !

Les fonctions partent en classe verte et chahutent bruyamment dans leur bus. Excédé, le chauffeur finit par les menacer : « Calmez-vous sinon je vous dérive toutes ! ».

Au fond du bus, exponentielle prend un sourire narquois : « M'en fous ! »

Un biologiste, un physicien et un mathématicien rentrent d'un congrès à Glasgow. Tout à coup, leur train s'arrête en pleine voie, et le biologiste tombe en arrêt devant un détail du paysage, un mouton noir :
— Ça par exemple, les moutons écossais sont noirs !

Le physicien le reprend immédiatement :
— Allons, un peu de sérieux, tout ce que nous pouvons dire, c'est qu'il y a des moutons noirs en Écosse.

Le mathématicien soupire alors :
— Un peu de sérieux voyons : tout ce que nous pouvons affirmer, c'est qu'il y a en Écosse au moins un mouton qui a au moins un côté noir !

Il y a quand même des choses pratiques en bash comme "a=$(( ${b} + 13 ))"

Qui est une syntaxe shell standard !

Que le système démarre sous dash et non bash est très bien car dash est plus léger, plus réduit et donc plus sur dans le système d'init. Par contre, c'est pénible que "/etc/X11/Xsession" sous en /bin/sh (je le passe en /bin/bash sur mes postes utilisateurs) car cela signifie que la session X11 n'est pas équivalente à une session ssh pour un utilisateur.

Et ?

Ou comment être obligé de tout changer quand seul l'écran cesse de fonctionner. Ou quand seule la carte mère cesse de fonctionner…

N'importe quoi. En utilisant une API spécifique, il faut coder un client. En utilisant un protocole existant mais en le détournant un peu, ici en changeant son port d'utilisation, il faut au pire coder aussi un client en réutilisant des bibliothèques existantes, au mieux adapter un client existant. Bref, moins de travail.

SFTP n'a pas été implémenté par beaucoup d'autres choses que clients SSH comme un bonus ("en plus du shell, vous pouvez transférer des fichiers!"). Les exceptions notables sont Cyberduck et Filezilla, pour autant que je sache. C'est peu pour un standard.

Aucune importance, une API spécifique n'a par définition été mise en œuvre par personne avant d'être créée ex nihilo.

ls n'auraient pas de protocole spécifique qu'ils feraient du "something-over-HTTP" (ce que beaucoup font en réalité).

Pourquoi ? Quel problème à proposer du SFTP à la place ?

Avec une vision pareille, dans dix ou vingt ans on n'aura plus aucun protocole standard, des API spécifiques de partout, des logiciels spécifiques pour chaque service, aucune fédération entre services… J'en frissonne d'avance.

Notez que ça a déjà commencé : à une époque on avait FTP, puis SFTP comme protocole standard et indépendant du service pour les transferts de fichiers, aujourd'hui la mode est aux clouds à API spécifique.

Je sais que c'est un bashisme. Ça sonne bien.

Je connais que c'est un bashisme. Ça sonne mal, ça n'est pas du tout français, le verbe connaître a l'air de ne prendre comme complément d'objet direct que des substantifs, en tout cas pas des propositions.

y'a pas grand monde qui s'en servait pour de vrai (et maintenir ouvertes des choses dans le vent c'est pas forcément une bonne idée)

Oh, tous les logiciels de calendrier prenant en charge Google Calendar, une paille !

Ils plient sous les protestations. Leur volonté d'origine était claire : fermeture, fermeture, fermeture.

On ne fait pas, parce que pour ça Debian devrait payer aux États-Unis pour chaque utilisateur. Les coupables dans tout ça, ce sont les majors et toute cette clique avec leur DRM breveté.

Il ne faut pas se tromper de coupable, il y a des tas de choses qui ne sont pas faisables en libre, et les auteurs de logiciels libres n'y sont pour rien et ne peuvent rien y faire. Téléphoner à quelqu'un d'autre qui utilise Skype ? Pas faisable avec du logiciel libre. Mettre de la musique sur un iTruc ? Pas faisable avec du logiciel libre. Etc.

Non, le souci c'est que les navigateurs, tous confondus, n'affichent aucun avertissement lorsqu'on transmet un mot de passe en clair, ce qui est bien pire que d'accéder à un site Web sécurisé par une clef non certifiée.

Pas vraiment. D'empêcher tout MITM autre que par une autorité de certification ou quelqu'un autorisé par une autorité de certification.

Intéressant, je n'étais pas au courant. Décidément, entre l'abandon partiel d'XMPP et la volonté loupée d'abandonner CalDAV, don't be evil aura vécu…

Une des constructions que je connais être un bashisme […]

Que je sais être…

https://wiki.ubuntu.com/DashAsBinSh

Non, il serait plus judicieux d'éviter d'utiliser les fonctionnalités spécifiques à Bash, qui sont la plupart du temps inutiles. Tes scripts n'en seront que plus portables et plus rapides à exécuter.

Ensuite, les tests mathématiques en Sh, non merci.

Avec test, alias [ ? Si tu trouves ça difficile, c'est mal barré, effectivement.

En outre, le /bin/sh est souvent un lien vers /bin/bash dans une partie des distributions (dans mon Archlinux par exemple)

Exact, et c'était le cas sous Debian et Ubuntu, qui sont passés à dash. L'évolution ne va pas vers bash, au contraire, on s'en débarrasse. Pour les scripts, j'entends, pas comme interpréteur interactif.

C'est dommage, parce qu'il vaut mieux être connecté en SSL avec une clef non certifiée qu'être connecté en clair pour transmettre un mot de passe. Une clef non certifiée est vulnérable aux attaques par interception — man in the middle — mais protège au moins des attaques par écoute simple et des introductions de nouveaux intercepteurs, contrairement à une connexion en clair qui ne protège de rien de tout ça.

En effet, mais Debian n'est pas française.

Parce que CAcert n'est pas reconnu par les navigateurs.

Oulà, je ne suis pas sûr de tout comprendre. Sois sûr qu'un attaquant se connectera bien au site en HTTPS : ce n'est qu'entre le client et l'attaquant que la connexion sera en HTTP.