Attention, je ne dis pas qu’utiliser OpenBSD, c’est être un hacker. Je parle bien de l’esprit hacker, celui de chercher à comprendre les choses, et les découvrir sous un autre angle ;)
Généralement, lorsqu’on n’est pas motivé, on abandonne quelque soit la tâche ou l’objectif ; cela n’a rien à voir avec le fait d’être entrainé ou pas. Je connais dees enseignants qui se sont mis à OpenBSD sans rien connaître à l’IT, en soit, utilisateurs de Linux au quotidien, donc se sont dit pourquoi pas, et y trouvent leur compte.
D’autres utilisateurs ont abandonné…
Je connais même des profils IT qui n’en veulent pas. Donc, vraiment ce n’est pas le fait d’être entrainé qui motive l’adoption, c’est la volonté personnelle.
Mais pour autant, faudrait-il déjà chercher à essayer, bref avoir de la volonté de découvrir, tester, chercher à comprendre - on rejoint ici l’esprit hacker initial ;)
Les divergences sont acceptables mais il faut reconnaître qu’il y a beaucoup de contradictions dans l’informatique libre. Généralement lorsqu’on n’est pas motivé et entraîné on abandonne irrémédiablement.
Pas utile pour l’utilisateur lambda ? c’est justement le but de tous mes articles : “lambadifier”… c’est d’ailleurs la raison pour laquelle j’ai cofondé il y a plusieurs années la communauté “OpenBSD Pour Tous” : faire en sorte qu’OpenBSD soit utilisable pour le béotien IT, ni plus ni moins.
Je n’ai aucun attrait pour le sysdev. Utilisateur Unix/Linux convaincu : assurément depuis fort, fort, fort longtemps.
Et d’OpenBSD depuis 2016, mais toujours à côté d’un sys Debian-like ou l’autre.
Mon constat : oui, OpenBSD est un OS facile à appréhender, qui peut être utiliser pour les besoins quotidiens (bureautique, internet, etc…) et utilisable, mais est vraiment fait pour et par des dév, assurément. Donc, pour l’utilisateur final, c’est viable, mais… y’a des efforts à faire pour rendre vraiment “user-friendly”, un peu comme sous Linux, ou d’autres BSD. Sauf que ce n’est pas le but de cet OS !
Donc des efforts de vulgarisation sont à faire ; que ne fait pas l’équipe… la charge utile est dans les mains d’utilisateurs convaincus, quelque soit la langue !
(cela n’enlève en rien la qualité des informations dans la FAQ Officielle, et encore mieux dans les manpages, qui est vraiment un cran supérieur, parce que sous OpenBSD, si la FAQ ou le manpage n’est pas correctement à jour, c’est un bug sérieux qui doit être résolu avant publication, ou à défaut, le plus rapidement possible afin que l’information soit pertinente, correcte et à juste titre…)
Merci pour l’article.
Je me suis posé la question de l’intérêt d’une fois par semaine, plutôt que d’une fois par jour, par exemple.
Le manpage répond :
Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week. Note that not
all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time.
une fois par jour semble ne pas être nécessaire, voire à éviter.
Voilà.
Je l’ai jamais utilisé mais du coup je me demande : pourquoi c’est un daemon ?
Pourquoi faire tourner un truc en fond juste pour une update de temps à autre ?
Par contre, je pense pas que ce soit quelque chose d’utile pour l’utilisateur lambda. On rentre dans de l’informatique pour les experts. Administrateur système -> Utilisateur Unix convaincu -> Attrait prononcé pour le développement système. Moi, en lisant ces ligne, avec retrait, j’ai pas l’impression qu’Unix ait un avenir.
Intéressant ! J’avais tenté le même genre avec un raspberry, voir si je peux l’alimenter en solaire, c’est malheureusement impossible sauf en surdimensionnant le projet.
Bonjour PengouinPdt, merci pour ces corrections. Et merci aussi pour le retour, c’est toujours agréable de voir que mon travail sert et est apprécié :).
Bjr. Tout d’abord, merci pour ces explications claires, limpides. Je ne m’étais jamais mis à la question, mais récemment je me suis fait la réflexion de l’intérêt de la chose.
Grâce à toi, j’ai compris le propos. Merci !
Sinon quelques coquilles :
tous les signaux ne peuvent pas être piégé <= piégés.
concret: <= concret : (nécessite un espace toujours devant les deux points)
la connexion maitre <= la connexion maître
intiée <= initiée
un signal standards su système <= un signal standard du système (pas de ‘s’ final à standard; + su/du)
ce qui ga générer <= ce qui va générer
changer se comportement <= changer ce comportement
problème: (voir remarque plus haut, concernant les deux points)
Dans notre script nous allons modifier un petit peu notre script (une certaine redondance qui alourdit le propos : proposition : Modifions un petit peu notre script.)
prévu: (voir remarque plus haut, concernant les deux points)
répétition : “Afin de disposer de plus de temps pour lancer la commande kill
Afin d’avoir le temps de lancer la commande kill,”
PID: (voir remarque plus haut, concernant les deux points)
Bonjour Salim, J’avoue, le mot piège est le prétexte pour faire le jeux de mot sur la célèbre phrase du Général Ackbar. Mais je suis d’accord avec vous.
Pour ce qui est de la complexité des script, tout dépend du point de vue. personnellement en tant qu’administrateur système je suis plus à l’aise avec des scripts shell qu’avec d’autre type de languages.
Je préfère le terme « capturer » au terme « piéger » : capturer renvoie à quelque chose de dynamique et dans le contexte, il a une connotation positive. Je trouve que les scripts Shell sont compliqués ; en fait, je pense qu’il faut avoir des connaissances générales, sinon c’est trop abstrait (on ne sait pas trop comment s’y prendre pour conduire l’ensemble).
Après relecture, je m’aperçois que mon premier message t’as induit en erreur, la causalité est dans l’autre sens.
Cat est un algo simple : il prend un input et l’affiche dans un output. Pour être performant, il libère la RAM au plus tôt et pour cela, il se débarrasse de ses données ASAP (il les affiche). L’affichage immédiat est donc la cause d’une consommation réduite : le programme en lui-même n’en a plus besoin.
Dans un système à faibles ressources, tu pourrais te retrouver avec une lenteur, mais jamais parce que cat charge la totalité du fichier, juste par spécificités du système.
Ce qui me bloque c’est que je ne comprends pas l’assertion « L’affichage est immédiat parce que la conso de RAM est constante (et faible) » : si possible, il me faudrait une explication (exposer les choses).
Très bon choix de livre, c’est une référence. Effectivement, la vitesse d’affichage est dépendante de ton archi, mais ce n’est pas là qu’est la vraie information de l’article en réalité. Cette phrase n’existe que pour faire un premier constat, constat qui est expliqué par le code. L’affichage est immédiat parce que la conso de RAM est constante (et faible) [EDIT: my bad, cette phrase est fausse. Cf. la suite de la conversation]. Le tout étant la conséquence du streaming de données. Au besoin, tu peux augmenter la taille du fichier pour tester les limites de ton propre système.
Avec ton Raspberry tu observes une latence qui peut être liée à d’autres paramètres dont j’ai pas conscience mais ça ne remet pas en question la logique interne de cat qui ne fait pas un « loadFileInMemory then print ». Ça se teste très facilement avec un trace. Je t’invite à jouer avec la stack de test que j’ai mise en place https://gitlab.com/prytoegrian/blog-codes/-/tree/main/consommation_memoire_cat en limitant la RAM de docker pour valider ton cas limite.
Pour la petite anecdote, je me suis aperçu que l’implémentation de cat sous alpine différait de celle sous debian ; la logique de streaming demeurait. Ça ne me choquerait pas qu’il y ai aussi quelques adaptations pour Raspberry.
Je lis le livre « Modern Operating Systems » de Andrew Tanenbaum, Herbert Bos & Co mais je n’en suis qu’au début. Ce qui me paraît étonnant c’est la corrélation qui est faite entre la consommation mémoire et l’affichage instantané à l’écran.
Lors du cat /tmp/1gib.test, quelque chose a dû vous sauter aux yeux : il n’y a pas d’attente, le fichier vous est affiché immédiatement et progressivement.
[…] (appels systèmes) Ce que nous pouvons en déduire, c’est que la lecture du fichier est progressive et envoyée directement à la sortie.
[…] cat conserve une empreinte mémoire la plus faible possible vu qu’il évite l’accumulation sur la RAM.
L’instantanéité perçue est relative à la « vitesse des opérations ». Sur mon Raspberry Pi l’affichage de la console Linux est très lent lors de la phase d’amorçage ou lors d’une compilation logicielle par rapport à un ordinateur portable avec un processeur puissant (autant de mémoire RAM disponible). Qu’en est-il en remplaçant le HDD (Hard Disk Drive) par un SDD (Solid State Drive) ? La réalité semble plus complexe (éloignée) que l’interprétation éclaire (erronée ?) qui en est faite dans l’article.
Merci pour tes conseils ! C’est fait pour le rajout des headers sur mon blog, ton site de test est top. J’ajouterais une note en fin d’article concernant cela, c’est très important tu as raison. Je ne pense pas ajouter une section car ça dépasse le simple cadre de “TLS” je trouve, même si c’est tout aussi important.
Pour Lets Encrypt, j’avais hésité car pour EC-256 j’avais trouvé ce post ( https://community.letsencrypt.org/t/why-is-the-nsa-deprecating-p256-ecdhe/142096 ) et EC-384 ne semble pas supporté aussi largement que RSA ? RSA4096 me paraissait un bon compromis. Mais ça évolue très vite dans ce domaine, je vais me renseigner si en effet EC-384 n’est pas plus pertinent aujourd’hui, auquel cas je modifierai ma recommandation dans l’article.
Je fais de même concernant la sécurité, je fais en sorte de pousser le hardening au détriment des utilisateurs.
Si l’utilisateur utilise IE ou une vieille version d’un navigateur, tant pis pour lui, de même pour les hacks CSS, je n’en mets pas.
Cependant j’aurais conseillé ECC au lieu de RSA (même en 4096), et plus précisément EC-256, ou au maximum EC-384, car si supérieur c’est encore trop mal supporté.
Un autre point non abordé concerne les headers, qui sont tout aussi importants, je te laisse voir ta note ici : https://securityheaders.com/
Peut-être le sujet d’un prochain article ?
Attention, je ne dis pas qu’utiliser OpenBSD, c’est être un hacker. Je parle bien de l’esprit hacker, celui de chercher à comprendre les choses, et les découvrir sous un autre angle ;)
Généralement, lorsqu’on n’est pas motivé, on abandonne quelque soit la tâche ou l’objectif ; cela n’a rien à voir avec le fait d’être entrainé ou pas. Je connais dees enseignants qui se sont mis à OpenBSD sans rien connaître à l’IT, en soit, utilisateurs de Linux au quotidien, donc se sont dit pourquoi pas, et y trouvent leur compte. D’autres utilisateurs ont abandonné… Je connais même des profils IT qui n’en veulent pas. Donc, vraiment ce n’est pas le fait d’être entrainé qui motive l’adoption, c’est la volonté personnelle.
Mais pour autant, faudrait-il déjà chercher à essayer, bref avoir de la volonté de découvrir, tester, chercher à comprendre - on rejoint ici l’esprit hacker initial ;)
Les divergences sont acceptables mais il faut reconnaître qu’il y a beaucoup de contradictions dans l’informatique libre. Généralement lorsqu’on n’est pas motivé et entraîné on abandonne irrémédiablement.
Pas utile pour l’utilisateur lambda ? c’est justement le but de tous mes articles : “lambadifier”… c’est d’ailleurs la raison pour laquelle j’ai cofondé il y a plusieurs années la communauté “OpenBSD Pour Tous” : faire en sorte qu’OpenBSD soit utilisable pour le béotien IT, ni plus ni moins.
Je n’ai aucun attrait pour le sysdev. Utilisateur Unix/Linux convaincu : assurément depuis fort, fort, fort longtemps. Et d’OpenBSD depuis 2016, mais toujours à côté d’un sys Debian-like ou l’autre.
Mon constat : oui, OpenBSD est un OS facile à appréhender, qui peut être utiliser pour les besoins quotidiens (bureautique, internet, etc…) et utilisable, mais est vraiment fait pour et par des dév, assurément. Donc, pour l’utilisateur final, c’est viable, mais… y’a des efforts à faire pour rendre vraiment “user-friendly”, un peu comme sous Linux, ou d’autres BSD. Sauf que ce n’est pas le but de cet OS !
Donc des efforts de vulgarisation sont à faire ; que ne fait pas l’équipe… la charge utile est dans les mains d’utilisateurs convaincus, quelque soit la langue ! (cela n’enlève en rien la qualité des informations dans la FAQ Officielle, et encore mieux dans les manpages, qui est vraiment un cran supérieur, parce que sous OpenBSD, si la FAQ ou le manpage n’est pas correctement à jour, c’est un bug sérieux qui doit être résolu avant publication, ou à défaut, le plus rapidement possible afin que l’information soit pertinente, correcte et à juste titre…)
Voilà
Merci pour l’article. Je me suis posé la question de l’intérêt d’une fois par semaine, plutôt que d’une fois par jour, par exemple. Le manpage répond :
Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week. Note that not all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time.
une fois par jour semble ne pas être nécessaire, voire à éviter. Voilà.
Ha ha perso je l’utilise en one shot justement à cause de ça, je mets à jour, je désinstalle fwupd ensuite.
Tcho !
Je l’ai jamais utilisé mais du coup je me demande : pourquoi c’est un daemon ? Pourquoi faire tourner un truc en fond juste pour une update de temps à autre ?
Pourquoi est-ce que l’audio et la vidéo ne sont pas gérés automatiquement ?
C’est en phase avec leur orientation.
Par contre, je pense pas que ce soit quelque chose d’utile pour l’utilisateur lambda. On rentre dans de l’informatique pour les experts. Administrateur système -> Utilisateur Unix convaincu -> Attrait prononcé pour le développement système. Moi, en lisant ces ligne, avec retrait, j’ai pas l’impression qu’Unix ait un avenir.
Intéressant ! J’avais tenté le même genre avec un raspberry, voir si je peux l’alimenter en solaire, c’est malheureusement impossible sauf en surdimensionnant le projet.
Il n’y a plus assez d’energie solaire pour alimenter le serveur web, il est en pls
Bonjour PengouinPdt, merci pour ces corrections. Et merci aussi pour le retour, c’est toujours agréable de voir que mon travail sert et est apprécié :).
Bjr. Tout d’abord, merci pour ces explications claires, limpides. Je ne m’étais jamais mis à la question, mais récemment je me suis fait la réflexion de l’intérêt de la chose. Grâce à toi, j’ai compris le propos. Merci !
Sinon quelques coquilles :
Afin d’avoir le temps de lancer la commande kill,”
;)
Bonjour Salim, J’avoue, le mot piège est le prétexte pour faire le jeux de mot sur la célèbre phrase du Général Ackbar. Mais je suis d’accord avec vous.
Pour ce qui est de la complexité des script, tout dépend du point de vue. personnellement en tant qu’administrateur système je suis plus à l’aise avec des scripts shell qu’avec d’autre type de languages.
Je préfère le terme « capturer » au terme « piéger » : capturer renvoie à quelque chose de dynamique et dans le contexte, il a une connotation positive. Je trouve que les scripts Shell sont compliqués ; en fait, je pense qu’il faut avoir des connaissances générales, sinon c’est trop abstrait (on ne sait pas trop comment s’y prendre pour conduire l’ensemble).
Après relecture, je m’aperçois que mon premier message t’as induit en erreur, la causalité est dans l’autre sens.
Cat est un algo simple : il prend un input et l’affiche dans un output. Pour être performant, il libère la RAM au plus tôt et pour cela, il se débarrasse de ses données ASAP (il les affiche). L’affichage immédiat est donc la cause d’une consommation réduite : le programme en lui-même n’en a plus besoin.
Dans un système à faibles ressources, tu pourrais te retrouver avec une lenteur, mais jamais parce que cat charge la totalité du fichier, juste par spécificités du système.
Ce qui me bloque c’est que je ne comprends pas l’assertion « L’affichage est immédiat parce que la conso de RAM est constante (et faible) » : si possible, il me faudrait une explication (exposer les choses).
Très bon choix de livre, c’est une référence. Effectivement, la vitesse d’affichage est dépendante de ton archi, mais ce n’est pas là qu’est la vraie information de l’article en réalité. Cette phrase n’existe que pour faire un premier constat, constat qui est expliqué par le code.
L’affichage est immédiat parce que la conso de RAM est constante (et faible)[EDIT: my bad, cette phrase est fausse. Cf. la suite de la conversation]. Le tout étant la conséquence du streaming de données. Au besoin, tu peux augmenter la taille du fichier pour tester les limites de ton propre système.Avec ton Raspberry tu observes une latence qui peut être liée à d’autres paramètres dont j’ai pas conscience mais ça ne remet pas en question la logique interne de cat qui ne fait pas un « loadFileInMemory then print ». Ça se teste très facilement avec un trace. Je t’invite à jouer avec la stack de test que j’ai mise en place https://gitlab.com/prytoegrian/blog-codes/-/tree/main/consommation_memoire_cat en limitant la RAM de docker pour valider ton cas limite.
Pour la petite anecdote, je me suis aperçu que l’implémentation de cat sous alpine différait de celle sous debian ; la logique de streaming demeurait. Ça ne me choquerait pas qu’il y ai aussi quelques adaptations pour Raspberry.
Je lis le livre « Modern Operating Systems » de Andrew Tanenbaum, Herbert Bos & Co mais je n’en suis qu’au début. Ce qui me paraît étonnant c’est la corrélation qui est faite entre la consommation mémoire et l’affichage instantané à l’écran.
L’instantanéité perçue est relative à la « vitesse des opérations ». Sur mon Raspberry Pi l’affichage de la console Linux est très lent lors de la phase d’amorçage ou lors d’une compilation logicielle par rapport à un ordinateur portable avec un processeur puissant (autant de mémoire RAM disponible). Qu’en est-il en remplaçant le HDD (Hard Disk Drive) par un SDD (Solid State Drive) ? La réalité semble plus complexe (éloignée) que l’interprétation éclaire (erronée ?) qui en est faite dans l’article.
Merci pour tes conseils ! C’est fait pour le rajout des headers sur mon blog, ton site de test est top. J’ajouterais une note en fin d’article concernant cela, c’est très important tu as raison. Je ne pense pas ajouter une section car ça dépasse le simple cadre de “TLS” je trouve, même si c’est tout aussi important.
Pour Lets Encrypt, j’avais hésité car pour EC-256 j’avais trouvé ce post ( https://community.letsencrypt.org/t/why-is-the-nsa-deprecating-p256-ecdhe/142096 ) et EC-384 ne semble pas supporté aussi largement que RSA ? RSA4096 me paraissait un bon compromis. Mais ça évolue très vite dans ce domaine, je vais me renseigner si en effet EC-384 n’est pas plus pertinent aujourd’hui, auquel cas je modifierai ma recommandation dans l’article.
Hello.
Je fais de même concernant la sécurité, je fais en sorte de pousser le hardening au détriment des utilisateurs.
Si l’utilisateur utilise IE ou une vieille version d’un navigateur, tant pis pour lui, de même pour les hacks CSS, je n’en mets pas.
Cependant j’aurais conseillé ECC au lieu de RSA (même en 4096), et plus précisément EC-256, ou au maximum EC-384, car si supérieur c’est encore trop mal supporté.
A noter que Caddy, par défaut porte une configuration TLS quasi parfaite, si ce n’est parfaite en terme de compromis : https://caddyserver.com/docs/caddyfile/directives/tls
Un autre point non abordé concerne les headers, qui sont tout aussi importants, je te laisse voir ta note ici : https://securityheaders.com/
Peut-être le sujet d’un prochain article ?