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 ?
Ahahhh, crontab.guru m’a sauvé bien des fois… de mes trous de mémoire.
Sinon, puisqu’une crontab est un réalité un fichier enregistré dans /var/spool/cron/crontabs, au nom de l’utilisateur - du moins sous Debian (et assimilés), l’astuce dont je me sers de plus en plus, au lieu d’écrire directement dans crontab, est la suivante :
écrire un fichier, exemple ‘crontab4tasks’ et le remplir des règles désirées en s’aidant au besoin du *guru.
exécuter la commande crontab en injectant le fichier.
crontab < crontab4tasks
Un des avantages que j’y perçois, hormis le fait de pouvoir utiliser un éditeur de texte pour créer les règles “facilement”, cela me permet de garder assurément une trace de la table de crons pour un utilisateur donné.
Même si je n’ai jamais été un grand fan de l’analytics de manière générale, XiTi a bercé ma jeunesse avec son infâme logo.
Je ne savais même pas que c’était Français et l’un des pionniers dans le domaine.
Une page de l’Internet se tourne. Chapeau à toute l’équipe.
Ça arrive dans un contexte de rachat, les différentes équipes peuvent avoir à uniformiser les outils utilisés.
Par contre, c’est pas de chance quand ça tombe sur un cas comme ça, avec deux outils dont le but est différent, et c’est celui qui n’est pas adapté au besoin qui est choisi pour rester ^^
Chez nous, Puppet et Ansible sont utilisés tous les deux, mais pour des tâches différentes : Puppet gère la conf persistante (OS, packages, etc.), tandis qu’Ansible est dédié aux tâches “oneshot” (déploiement applicatif, déclaration dans l’AD, etc.).
Mais c’est justement le but de l’article de présenter ces syntaxes obscures du langage C. Même si leur utilité est faible, ce sont des cas que l’on peut rencontrer. Par exemple dans le noyaux Linux ou dans les soumissions de l’IOCCC.
J’insiste sur présenter la syntaxe et pas des cas d’utilisation de ces syntaxes. Car je pense qu’en contexte, c’est plus compliqué à comprendre que dans un exemple simple qui n’a que peu de sens.
Je trouve que toute la beauté de la chose est de trouver quand utiliser ces syntaxes lorsqu’elles se révèlent intéressantes. Certaines comme “le tableau flexible” ou “les caractères trop spéciaux” ne sont pas intéressantes de nos jours mais on peut les retrouver dans d’anciens codes sources.
Le problème est qu’on passe à côté de l’essentiel en montrant (également) ce pour quoi le langage n’a pas été conçu. Ce n’est pas juste pour critiquer que j’ai relevé tel ou tel point. Bref, ce n’est que mon opinion.
C’est fou mais il manque la balise menu et donc peut-être d’autres.
Je n’ai pas bien compris pourquoi certaines balises sont qualifiées d’expérimentales mais ok.
Aussi, je ne connaissais pas la balise rtc ! Elle ne semble pas être standard (je ne l’ai pas trouvé dans le standard HTML 5) mais je suis content de l’avoir découverte.
Chez mon employeur actuel, on vient de faire l’inverse : Adieu Ansible et Go puppet. Pour la partie orchestration, puppet + choria fonctionne très bien
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 ?
Merci pour le tips :)
Ahahhh, crontab.guru m’a sauvé bien des fois… de mes trous de mémoire.
Sinon, puisqu’une crontab est un réalité un fichier enregistré dans /var/spool/cron/crontabs, au nom de l’utilisateur - du moins sous Debian (et assimilés), l’astuce dont je me sers de plus en plus, au lieu d’écrire directement dans crontab, est la suivante :
écrire un fichier, exemple ‘crontab4tasks’ et le remplir des règles désirées en s’aidant au besoin du *guru.
exécuter la commande crontab en injectant le fichier.
crontab < crontab4tasksUn des avantages que j’y perçois, hormis le fait de pouvoir utiliser un éditeur de texte pour créer les règles “facilement”, cela me permet de garder assurément une trace de la table de crons pour un utilisateur donné.
Voilà.
Même si je n’ai jamais été un grand fan de l’analytics de manière générale, XiTi a bercé ma jeunesse avec son infâme logo. Je ne savais même pas que c’était Français et l’un des pionniers dans le domaine. Une page de l’Internet se tourne. Chapeau à toute l’équipe.
Ça arrive dans un contexte de rachat, les différentes équipes peuvent avoir à uniformiser les outils utilisés.
Par contre, c’est pas de chance quand ça tombe sur un cas comme ça, avec deux outils dont le but est différent, et c’est celui qui n’est pas adapté au besoin qui est choisi pour rester ^^
Chez nous, Puppet et Ansible sont utilisés tous les deux, mais pour des tâches différentes : Puppet gère la conf persistante (OS, packages, etc.), tandis qu’Ansible est dédié aux tâches “oneshot” (déploiement applicatif, déclaration dans l’AD, etc.).
Si tu parles du fait de se brancher sur la prise TIC, oui, c’est tout à fait légal, elle est là pour ça (le “C” veut dire “Client” ^^).
L’accès à tout ce qui n’est pas plombé est autorisé, et on voit sur la photo que le plomb est à coté ;)
La vidéo n’étant disponible que 7 jours, la rediffusion (CC-BY) est disponible sur youtube : https://www.youtube.com/watch?v=sNAknU5g5QE
La vidéo n’étant disponible que 7 jours, la rediffusion (CC-BY) est disponible sur youtube : https://www.youtube.com/watch?v=uerlqRSVYEs
Mais c’est justement le but de l’article de présenter ces syntaxes obscures du langage C. Même si leur utilité est faible, ce sont des cas que l’on peut rencontrer. Par exemple dans le noyaux Linux ou dans les soumissions de l’IOCCC.
J’insiste sur présenter la syntaxe et pas des cas d’utilisation de ces syntaxes. Car je pense qu’en contexte, c’est plus compliqué à comprendre que dans un exemple simple qui n’a que peu de sens.
Je trouve que toute la beauté de la chose est de trouver quand utiliser ces syntaxes lorsqu’elles se révèlent intéressantes. Certaines comme “le tableau flexible” ou “les caractères trop spéciaux” ne sont pas intéressantes de nos jours mais on peut les retrouver dans d’anciens codes sources.
J’ai de la peine à voir l’intérêt de ce genre d’articles… Un simple lien aurait suffit.
Le problème est qu’on passe à côté de l’essentiel en montrant (également) ce pour quoi le langage n’a pas été conçu. Ce n’est pas juste pour critiquer que j’ai relevé tel ou tel point. Bref, ce n’est que mon opinion.
C’est fou mais il manque la balise menu et donc peut-être d’autres.
Je n’ai pas bien compris pourquoi certaines balises sont qualifiées d’expérimentales mais ok. Aussi, je ne connaissais pas la balise rtc ! Elle ne semble pas être standard (je ne l’ai pas trouvé dans le standard HTML 5) mais je suis content de l’avoir découverte.
Juste parce qu’on a fait une boulette et que la précision, c’est bien, c’était pas un event root-me pro mais un event root-me.
Juste parce qu’on a fait une boulette et que la précision, c’est bien, c’était pas un event root-me pro mais un event root-me.
une raison particulière à l’abandon de Ansible ?
Il en fait pour tous les goûts. Bonne chance
En terme de perf, ça tenait ?
Chez mon employeur actuel, on vient de faire l’inverse : Adieu Ansible et Go puppet. Pour la partie orchestration, puppet + choria fonctionne très bien