Je n'ai au contraire jamais croisé la règle (ALL, !root), pas même en configuration par défaut. Ou peut-être que c'est la règle par défaut dans Mac OS, ce qui expliquerait pourquoi c'est eux qui ont trouvé la faille :).
Freetube et Invidious ne sont pas des alternatives, faut pas confondre. Perso pour YouTube, flux RSS + youtube-dl/MPV. De temps en temps j'utilise l'interface web pour chercher des trucs, mais c'est une assez petite partie de mon utilisation.
J'avais personnellement entendu parlé de https://invidio.us/ avant FreeTube, ce dernier en utilise d'ailleurs l'API pour indexer les résultats il me semble
Le Wiki pas joignable lors d'une opération ou d'un gros problème, grand classique. Ça arrive aussi pour les mots de passe, pas dispo parce que justement l'opé porte sur le serveur qui les héberge ha ha.
Je salue le titre de l'article ça donne direct envie de le lire ^^
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.
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.
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.
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.
Je n'ai au contraire jamais croisé la règle (ALL, !root), pas même en configuration par défaut. Ou peut-être que c'est la règle par défaut dans Mac OS, ce qui expliquerait pourquoi c'est eux qui ont trouvé la faille :).
Une faille exploitable seulement avec une mauvaise configuration de sudo, mais malheureusement beaucoup de configuration par défaut comme ça.
Sudo devrait seulement être configurer avec une liste blanche et non avec une liste noire.
pour la procédure Android, il y a des détails et infos supplémentaires ici https://www.latelierdugeek.fr/2019/06/14/dupliquer-son-badge-dimmeuble-avec-un-smartphone-cest-facile/ et en complément à une question que je me suis posé https://rfid.ooreka.fr/qr/voir/498925/mon-smartphone-equipe-nfc-peut-il-servir-de-badge-rfid-passif-programmable
Oui oui alternative c'est pas forcément le bon mot. Le bon terme aurait été “moyen de consommation alternatif” de YouTube si tu veux :)
Freetube et Invidious ne sont pas des alternatives, faut pas confondre. Perso pour YouTube, flux RSS + youtube-dl/MPV. De temps en temps j'utilise l'interface web pour chercher des trucs, mais c'est une assez petite partie de mon utilisation.
J'avais personnellement entendu parlé de https://invidio.us/ avant FreeTube, ce dernier en utilise d'ailleurs l'API pour indexer les résultats il me semble
À part Peertube je n'en connais pas https://joinpeertube.org
Et vous, quelles sont vos alternatives à YouTube ?
Et encore, y'a pire : https://twitter.com/rivatez/status/1183579402539388928
Le Wiki pas joignable lors d'une opération ou d'un gros problème, grand classique. Ça arrive aussi pour les mots de passe, pas dispo parce que justement l'opé porte sur le serveur qui les héberge ha ha.
Je salue le titre de l'article ça donne direct envie de le lire ^^
Tcho !
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 -eudans 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.-erends les scripts plus lisible à mon goût.Ah mais j'ai pas dis le contraire. Je dis juste que
! trueretourne 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 detest -zoutest -nles variables qui doivent absolument ne pas être vides (et j'ai aussi des cas de variables légitimement vides).Après, mettre
-eupar défaut et ne le virer que quand on a besoin (avecsetpar 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.
As-tu essayé le bout de script que j'ai partagé ?
! truen'arrête pas le script. C'est à dire que-eignore 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.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.