Rien n'empêche de limiter la bande-passante avec un outil comme pfSense sans nécessairement mettre en place une politique de blocage :)

Un argument que l'on oublie souvent, c'est qu'en zone rurale, la bande passante est très limitée. Donc obligé d'interdire l'accès à tout ce qui est récréatif parce qu'autrement plus personne ne peut bosser.

« il faut renouveler toutes ces actions tous les mois pour compenser la petite taille des clés cryptographiqes » Euh non, ça n'a rien à voir avec la taille des clés, c'est pour éviter les attaques par rejeu.

Sinon, pour le thème principal de l'article : ce n'est pas le fait que ce soit un sous-domaine qui nécessite du travail, c'est le fait que ce soit une sous-zone. Beaucoup de gens délèguent les sous-domaines, en en faisant ainsi une sous-zone, sans que ce soit nécessaire. Ils se compliquent ainsi la vie pour rien.

Merci pour vos commentaires !

Tout à fait d'accord sur le principe de respecter les règles lorsque l'on rejoint une organisation, quelle qu'elle soit.

Je pense aussi que dans ce genre de contexte, l'avenir de la personne ne devrait dépendre que d'elle même.

Si elle décide de regarder des vidéos de Fortnite plutôt que de réviser son cours de philosophie, c'est son problème et ça ne regarde que la personne.

Tant qu'elle respecte les autres, il ne devrait pas y avoir de restrictions.

Pour une seule personne regardant Fortnite, on empêche les 9 autres d'accéder à une vidéo TED ou Datagueule, qui certes n'a pas nécessairement de rapport direct avec le cours, mais reste un moyen d'élargir notre champ de connaissance, et de ne pas se restreindre à la vision portée par le cours pensé exclusivement par quelqu'un d'autre que soit.

Mais en effet, tout dépend du cadre, cela peut être plus compliqué selon le cadre dans laquelle se situe la personne. Du coup, libre à chacun de changer de cadre si les règles ne lui conviennent pas. Et notamment, si l'on reprend le cas de l'école, peut-être que la personne se sentirait mieux dans une école démocratique par exemple.

Exactement, il m'arrive d'encadrer du code pas fiable avec set +eu; ...; set -eu dans le pire des cas. C'est très rare dans mon expérience.

Je trouve que les if $? ... sont très verbeux. Pire, j'ai vu un collègue écrire des script avec && à la fin de chaque ligne. -e rends les scripts plus lisible à mon goût.

Ah mais j'ai pas dis le contraire. Je dis juste que ! true retourne 1. Même s'il arrête pas le script, ça fausse le code de sortie. ! sert avant tout à inverser le code de retour, pas à l'ignorer. Ça c'est qu'un effet de bord.

Quant à -u, ça permet d'éviter pas mal d'arrachages de cheveux. Perso je teste systématiquement à coup de test -z ou test -n les variables qui doivent absolument ne pas être vides (et j'ai aussi des cas de variables légitimement vides).

Après, mettre -eu par défaut et ne le virer que quand on a besoin (avec set par exemple), c'est plutôt une bonne idée, surtout si on a pas l'habitude de certains comportements de Bash (qui varient de ce qu'on trouve ailleurs).

Bref, question d'habitude, chacun fait ce qu'il veut, tant que c'est en connaissance de cause.

Ça sert à « inverser » le code de retour

As-tu essayé le bout de script que j'ai partagé ? ! true n'arrête pas le script. C'est à dire que -e ignore le retour de !, quelque soit le résultat de la commande. En début de commande, ! est en bash comme le - de GNU Make. C'est un autre usage de !.

Toute erreur non gérée doit être une rédhibitoire.

Heu… non, certainement pas. Ça sert à « inverser » le code de retour, l'effet d'ignorer les erreurs qui suivent n'est qu'un effet de bord. Et ça rends inexploitable le code de retour de la commande (sauf à vouloir explicitement inverser le résultat).

Autant adapter ses scripts à son usage, je veux bien, autant utiliser des bricolages du langage, bof. Sans parler de la lisibilité qui en prends un coup…

Personnellement, je préfère traiter les erreurs (pré-vérifications, récupérations des codes d'erreurs et/ou de la sortie pour déterminer les actions à faire, etc) plutôt que d'activer un réglage Bash qui pourrait me mettre des bâtons dans les roues (en ne catchant pas certains cas que je considère comme erreur malgré le code 0, ou en catchant des cas que je ne trouve pas anormaux malgré le code de retour > 0).

Il m'arrive d'utiliser -e, mais généralement je l'active que quand j'ai tout un bloc de commandes lancées sans conditions à la suite et qui ne sont pas censées foirer. Du coup si ça plante à cet endroit, c'est qu'il y a un cas totalement imprévu.

Au final, ça dépends de la situation, des préférences et habitudes, etc.

Mieux vaut ignorer explicitement les erreurs. ! joue ce rôle.

#!/bin/bash -eux
! false
! true
echo "on continue"

Notons cependant qu'ils peuvent être inutilisables en script. Dès qu'on commence à faire des trucs un peu complexes, ça peut vite péter. J'ai quelques scripts qui supportent pas -e (ça pète pour rien).

Pour une suite de commandes à la makefile, ça se tiens, mais sinon c'pas toujours possible. Activer/désactiver les options au besoin à coup de set est intéressant et éviter de couper l'exécution durant un traitement correct.

Merci pour l'explication complète :)

Notons que l'article de Libération est mensonger : « une offre inédite dans le monde des médias » (Et NextInpact, alors ?)

Petit conseil de lecture à ce sujet. “Éloge du carburateur” de Matthew B. Crawford. Un essai sans prétention (ou alors un tout petit peu) sur le sens et la valeur du travail. C'est l'histoire d'un mec qui a bossé dans un think tank et qui en avait marre de son boulot à la con. Du coup il est devenu mécano de moto, et dans ce bouquin passionnant, il nous raconte tout ce que ça a changé dans sa vie. Je conseille. Perso, ça m'a fait comprendre pourquoi j'aime bien mon boulot, du coup.

-e délenche l'arrêt du script en cas d'erreur non gérée. Cela évite l'effet boule de neige où une erreur d'un script déclenche une avalanche d'erreur dans les commandes suivantes du script. Avec -e, bash s'arrête et affiche l'erreur à l'origine de toute la catastrophe qui aurait put se passer ensuite.

-u change le comportement de bash en regard des variables indéfinie. Par défaut, une variable indéfinie est substituée par la chaîne vide. Avec -u, bash lève une erreur et arrête le script. Cela évite notamment les erreurs avec le typo dans un nom de variable.

-eu est en quelque sorte le mode strict de bash, pour reprendre une terminologie de PHP. Autant, en interactif, -eu sont inutilisables, autant dans un scripts ils me semblent indispensables.

Une petite explication du pourquoi ?

Ils ne savaient pas que c'était impossible, alors ils l'ont fait.

Réussir à analyser le sens du papier toilette et faire le lien sérieusement avec le métier de consultant, c'est magnifique.

Je suis à la fois subjugué et consterné.

Si vous voulez l'accès au mp3 directement : http://rf.proxycast.org/1624240544773316608/18405-08.10.2019-ITEMA_22170365-0.mp3 (allez directement à 07:31 pour éviter la pub et les chansons…)

Mettez #!/bin/bash -eu et sauvez un chaton d'une mort effroyable !

PuTTY est un émulateur de terminal doublé d'un client pour les protocoles SSH, Telnet, rlogin, et TCP brut. Cf. Wikipedia.

Dans le sens où il émule un terminal.

Putty, un émulateur ? Sérieusement ? Ils ont fumé quoi chez Dévelopez ? Encore un Windowseux qui ne comprend rien à la ligne de commande !