Benoît Sibaud a écrit 10377 commentaires

SSH je dirais non (pour 20 ans). SSH protocole v1 1995, protocole v2 2006. Et la v1 n'est plus dans les derniers OpenSSH.

C'est surtout lui qu'il faut remercier. C'est lui qui nous a contacté. Il a dit KPTN, j'ai dit koi ? Et j'ai vu qu'il était Sensible.

FASTEN fournit des liens vers ses logiciels et leurs licences.

Quelques liens dans la catégorie SBOM :
- CycloneDX et sa liste de logiciels
- SPDX (qui a déjà son étiquette ici)
- Tern pour conteneurs/images Docker

(et du BOM en logiciel libre mais pour le matériel https://github.com/mpkasp/django-bom )

Corrigé, merci.

Et Ian Kelling a été choisi par les salariés pour les représenter au conseil.
https://www.fsf.org/news/welcoming-ian-kelling-to-staff-seat-on-fsfs-board-of-directors

Corrigé, merci.

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/main/db/schema.png
https://github.com/linuxfrorg/linuxfr.org/blob/main/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).