Benoît Sibaud a écrit 9300 commentaires

D'habitude les couches captent l'eau avec de la poudre…

site:fsf.org +"Server Side Public License"
https://static.fsf.org/nosvn/licensing/2020/proliferation.odp
https://media.libreplanet.org/mgoblin_media/media_entries/2368/LibrePlanet2020Pres.pdf (qui est une présentation d'une personne de l'OSI)

site:gnu.org +"Server Side Public License"
https://savannah.gnu.org/forum/forum.php?forum_id=9366 (un avis d'un projet)

Tu ne peux pas savoir qui a mis les étiquettes sur ce journal. N'importe qui peut étiqueter (et la modération peut masquer les étiquettes).

C'est clean !

Presque, je n'ai jamais réussi à avoir un espacement à gauche entre la bordure et le texte… mais bon l'esthétique n'était pas forcément la priorité quand j'ai eu besoin du schéma.

https://github.com/jgraph/drawio
https://www.diagrams.net/blog/move-diagrams-net

pour linuxfr.org, je m'étais rabattu sur draw.io (donc très manuel, mais je voulais de toute façon ajouter des précisions à divers endroits) :
https://github.com/linuxfrorg/linuxfr.org/blob/master/db/schema.png
https://github.com/linuxfrorg/linuxfr.org/blob/master/db/schema.drawio

Je sais. Mais à cause des États-Uniens, quand tu vois XX-YY-ZZZZ tu dois te demander si c'est une date française ou américaine, alors que ZZZZ-WW-VV est clair. Et en plus dans un cours de shell, les dates ISO permettent les tris lexicographiques. Mais c'était une simple remarque, le choix qui a été fait est tout à fait logique (des dates « françaises » pour des étudiants étudiant en français).

J'adore. J'ai passé un bon moment à faire le TP. Merci beaucoup.

Une PR pour améliorer divers points (principalement de l'orthographe) : https://github.com/phyver/GameShell/pull/13

Remarques diverses :

• le tgz ne devrait pas être dans le dépôt git (plus une question de principe qu'un vrai souci vu la taille, mais on a deux fois le code du coup, et il faut les synchroniser à chaque commit en théorie)
• je m'attendais à trouver du shellcheck quelque part (dans le jeu ou pour valider le jeu)
• bin/ ne contient pas des binaires (oui bon ok c'est très courant)
• la mission 12 suppose une date à la française et pas à l'américaine (vu que tout est en français c'est logique, mais les dates ISO c'est mieux :))

J'ai neutralisé les deux liens du commentaire précédent pour ne pas contribuer à leur référencement

J'ai supprimé le lien problématique dans le paragraphe précédent.

Terminus : un jeu d’aventure pour apprendre à utiliser la ligne de commande
https://linuxfr.org/news/terminus-un-jeu-d-aventure-pour-apprendre-a-utiliser-la-ligne-de-commande

Point. C'est ce qui est fait. Il peut y avoir des "dommages collatéraux" comme la lecture du code. Mais en même temps, qui va lire le code ? 99% des gens n'ont pas la compétence nécessaire, et parmi le 1% restant, 99.99% s'en foutent royalement.

Donc au bout d'un moment, faut arrêter. La question qui se pose est donc : est-ce qu'on tient compte des 0.00001% qui veulent tel truc quitte à perdre en efficacité ? La question, elle est vite répondue, et ce n'est pas une question d'intention, seulement d'efficacité.

Non on parle de sécurité informatique là… Même si seulement 0,00001% s'y intéressent, ils devraient pouvoir faire les vérifications utiles (on vire pas les algorithmes de cryptographie parce que 0,0001% seulement s'y intéressent, pour faire un parallèle, et pourtant ces algos nuisent à l'efficacité).
En l'occurrence ici, tu peux avoir besoin de pouvoir montrer que le code minifié correspond au code non-minifié d'origine par exemple (donc un déterminisme dans la minification). Ce qui permet par exemple de vérifier le code d'origine plutôt que le code minifié. Évidemment si tu fais du code non public / propriétaire dont seule la version minifiée est disponible, tu dis aux gens qui voudraient auditer niveau sécu "démerdez-vous".
Tu pourrais servir le code non minifié à côté du code minifié aussi (ça coûte rien à part du disque, si personne n'y accède).
Bref on peut réfléchir à la question sans tout balayer en disant minifier c'est plus efficace (ce qui est vrai en termes de taille/débit réseau).

Red Hat https://www.redhat.com/en/blog/red-hat-statement-about-richard-stallmans-return-free-software-foundation-board
Debian General Resolution https://www.debian.org/vote/2021/vote_002

Le marketing, la surconsommation, la mode, l'usure prématurée, la mauvaise qualité et les droits d'auteur pour ses descendants ?

• April https://april.org/retour-de-richard-stallman-au-conseil-d-administration-de-la-fondation-pour-le-logiciel-libre-fsf
• EFF https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board
• FSF https://www.fsf.org/news/preliminary-board-statement-on-fsf-governance
• OSI https://opensource.org/OSI_Response (empêtrée dans un souci d'élection du board justement… https://opensource.org/election_rerun et https://opensource.org/election_update ) …

• Tu ne fais pas un couteau-suisse 8347846378 d'outils. Générique / spécialisé, ou être bon dans certains domaines et être pas terrible ou carrément absent sur d'autres.
• Le poids de l'historique : le langage a été fait à un moment donné, avec les connaissances de l'époque, et il faut rester plus ou moins rétrocompatible
• Évolutions des connaissances : l'informatique a progressé dans les langages, mais les dernières nouveautés ne sont pas forcément dans les anciens langages, ou pas toutes, ou pas encore
• Les goûts et les couleurs : la meilleure syntaxe c'est {camelcase,snakecase,spacecake,quesaisje} et il faut un garbage collector et ne pas en avoir, des points virgule en fin de ligne ou des espaces au début, être compilé et/ou interprété, multiplateforme, multiarchitecture, etc., etc.
• Chacun veut le sien
• Personne ne connaît tous les langages existants, donc on peut réinventer dans son coin.
• La popularité ne dépend pas forcément du langage lui-même (mais de son écosystème, du marché du travail ou de la réputation, etc.)
• La résistance au changement : le COBOL est forcément mieux que le Crystal, il s'est bonifié comme le bon fromage…
• Il faut aussi accepter les échecs : oh un nouveau langage qui a l'air génial… bon finalement non
• Tout le monde a son langage qui va révolutionner et devenir la norme et tout remplacer. C'est juste que ce n'est jamais le même…
• …

C'est une position un peu dangereuse sur le principe… Tous ceux qui ne font pas comme le plus meilleur de la classe seraient à blâmer, si je résume caricaturalement. Corollaire : aucune chance pour un petit d'arriver sur le marché, ou un moyen de grossir, il doit arriver en ayant minimum 3 régions, 9 zones de disponibilités, des coûts faibles, avoir fait des économies d'échelle et avoir déjà fait la R&D, etc. (sans parler des éventuels critiques qui pourraient être faites sur ledit premier de la classe lui-même ; il n'a même pas des datacenters sur 3 planètes… ). L'important est plutôt d'être clair sur ce qu'on fait et ce qu'on ne fait pas (potentiellement pas encore), sans la couche de baratin de commerciaux et les buzzwords pour dirigeants.

Rectification du titre : le test est fait sur une Debian testing Bullseye

Concernant le scp -C, on peut mentionner que le serveur peut refuser de faire la compression, même si le client le demande (option Compression de ssh_config/sshd_config).

RMS devrait choisir entre GNU wget et curl ? S'il veut juste télécharger (potentiellement récursivement), fonctionnellement wget est plus simple à utiliser.

Fait, merci pour ce retour.

Et personne pour râler parce que je n'ai pas testé depuis la version de développement ? (ma correction pour le premier test que j'ai corrigé était inutile pour la version de développement, où le test avait été réécrit différemment…) Je m'auto-blâme seul dans mon coin alors (de toute façon cher moi et cher journal, nous sommes en tête à tête ici a priori).

$ git clone https://github.com/curl/curl
$ cd curl
$ libtoolize --force
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
$ autoconf
 $./configure --with-libssh2 --with-zstd --with-gssapi=/usr --enable-sspi --with-nghttp2 --with-zsh-functions-dir=/usr/share/zsh/vendor-completions --with-lber-lib=lber
$ make
$ make check
(...)
TESTDONE: 1418 tests were considered during 629 seconds.
TESTDONE: 1192 tests out of 1233 reported OK: 96%

TESTFAIL: These test cases failed: 582 600 601 602 603 604 605 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 633 634 635 636 637 638 639 640 641 642 664 665 1446 2004
# certaines erreurs viennent de "/usr/bin/env: «·python·»: Aucun fichier ou dossier de ce type"
$ sudo apt install python-is-python3
$ make check
(...)
TESTDONE: 1418 tests were considered during 482 seconds.
TESTDONE: 1195 tests out of 1236 reported OK: 96%

TESTFAIL: These test cases failed: 582 600 601 602 603 604 605 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 633 634 635 636 637 638 639 640 641 642 664 665 1446 2004

Bon c'est les 41 mêmes désormais…

Vous arrivez à vous affronter tout en disant tous les deux que ce logiciel mérite qu'on en parle ?

Alors :

• en parler dans un lien est tout à fait possible (la preuve)
• il est tout à fait possible que ce lien mérite un journal ou une dépêche, que plus d'infos soient données, que quelqu'un nous parle de son expérience personnelle ou qu'il soit comparé à d'autres solutions du même genre, s'il en existe (à ce stade je n'ai toujours pas cliqué sur le lien perso…)
• avantages/inconvénients selon moi
  • lien : rapide à écrire, rapide à publier, pas peu descriptif en soi, facile à manquer, beaucoup moins de visibilité qu'une dépêche (ou même qu'un journal a priori)
  • journal : plus long à écrire, rapide à publier, il faut détailler plus, on peut y caser l'expérience personnelle de son choix avec ses mots, plus de visibilité, probablement plus de fautes sur la forme ou d'oublis/erreurs sur le fond vu l'absence potentielle de relecture
  • dépêche : plus long à écrire, plus long à publier, possibilité de co-écriture, plus d'auteurs, moins personnel, beaucoup plus visible, relecture en rédaction et en modération, rapporte du karma, dispose d'une icône de section et de compteurs sur certains liens

Les 10 sur les conversions viennent du fait que le test impose la locale en_US.UTF-8 (pas de chance, sur cette machine il n'y avait que en_GB.UTF-8). Une fois cette locale ajoutée (sudo dpkg-reconfigure locales), les 10 passent. Je ne sais pas si ça mérite un rapport de bug (ni quoi proposer en solution en fait). Mais en tout cas, plus que 41.

* curl 7.75.0 (x86_64-pc-linux-gnu) 
* libcurl/7.75.0 OpenSSL/1.1.1j zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
* Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

52 tests en erreur regroupables ainsi a priori :
- 41 semblent être des soucis liés à la partie libssh2 "SSH public key authentication failed: Callback returned error".
- 10 semblent liés à des soucis de conversion de chaîne de type "Info: Failed to convert åäö.se to ACE; could not convert string to UTF-8"
- après le lancement initial et un autre lancement pour avoir des logs (tous deux en erreur donc), le suivant a marché sur le lancement suivant, ainsi que sur la centaine de suivants pour vérifier si c'était une instabilité… Là je me rappelle que j'ai passé la locale à C avant de lancer les derniers tests. Bingo.

--- log/check-expected  2021-03-20 18:43:51.115993579 +0100
+++ log/check-generated 2021-03-20 18:43:51.115993579 +0100
@@ -1 +1 @@
-0 says 7 Failed to connect to 127.0.0.1 port 47: Connection refused[LF]
+0 says 7 Failed to connect to 127.0.0.1 port 47: Connexion refusée[LF]

Bon a priori, ça c'est fait. Plus que 51.