g++ : les paramètres indispensables

Comme je suis toujours occupé à 3000 trucs en même temps, il arrive que mes articles soient absolument sans liens avec les précédents. C’est le cas de celui-ci. Je révise en ce moment C++, et pour bien l’utiliser il convient de réviser également l’utilisation du compilateur g++, lui-même issu de la suite GCC. Je prends (plutôt volontairement) ce programme en exemple pour cet article : #include <iostream> using namespace std; int main(int argc, char **argv) { cout << "Hello, you're on my blog :)" << endl; return(0); } Le programme le plus simpliste écrit en C++. Pour le compiler, le premier réflexe serait de faire tout simplement :

Sauvegarder ses flux Feedly sur AWS S3 : feedly2s3

Feedly est mon outil de veille depuis maintenant 6 ans. C’est un aggrégateur de flux qui propose des options payantes (comme Leo, l’assistant filtrant les articles de notre choix) mais gratuit de base. Note : vous trouverez la liste des abonnements ici, personnellement j’ai un abonnement Pro+. Comme sur tous les aggrégateurs de flux RSS, il est possible d’exporter la liste que l’on a créé au fur et à mesure du temps dans un fichier afin d’en faire une sauvegarde ou tout simplement pour le réimporter ailleurs. Par exemple, moi, toutes les semaines, j’en exporte une liste pour la conserver.

Une autre façon de cacher ses fichiers sous GNU/Linux

Jusqu’à présent, cacher mes fichiers était vite fait : je les renommais avec un “.” devant leur nom et basta. Je suis tombé aujourd’hui sur une autre façon de faire que je vous partage. Il suffit de créer un fichier texte dans le répertoire dont on souhaite cacher des fichiers/sous-répertoire et le nommer .hidden. Dans ce fichier, il faut simplement écrire un nom de fichier/répertoire par ligne. ➜ ~ cat .hidden perl5 snap ➜ ~ ls Bureau dev images perl5 snap Téléchargements Fermez votre navigateur de fichier, rouvrez-le et vous ne verrez plus les répertoires/fichiers dont les noms sont écrits dans votre fichier .

Migration Scaleway : Note #2

Hello, Voici dans un petit billet la suite de la première note décrivant la migration que j’ai entreprise, à savoir de mon infrastructure perso de AWS à Scaleway. Pour le moment, j’ai migré : toutes mes EC2 mes deux instances RDS (lab et prod) mon bucket s3 fourre-tout dans un bucket Object Storage Et actuellement, je suis sur deux fronts : du monitoring, j’ai choisi pour le coup Grafana/InfluxDB mon gitlab, qui va être le centre névralgique de mon CV ainsi que de ce blog, puisqu’il va héberger le code de mes sites (et d’autres choses) ainsi que lancer par CI/CD les conteneurs hugo poussant en ligne mes apps web Rappel de l’objectif final :

Migration Scaleway : scaleway-cli

Chez AWS, on a awscli, chez Google Cloud on a gcloud, chez Azure on a az, etc. Le concept est le même, un outil pour manager ses ressources depuis la ligne de commande en utilisant l’API du provider. C’est donc une des premières choses que j’ai recherché chez Scaleway après avoir démarrer ma migration. Et j’ai rapidement trouvé : scaleway-cli, aussi nommé scw ! L’outil est écrit en Go (et vient d’ailleurs de sortir en version 2.0), et est proposé via le repository Github du projet. Deux choix s’offrent à vous : le compiler ou poser le binaire dans votre $PATH.

Migration Scaleway : Note #1

Je vous parlais dans l’article précédent de ma volonté de migrer mon infrastructure personnelle chez Scaleway. Du coup, je vais pondre de temps en temps des petites notes comme celle-ci pour vous parler de l’avancement. Juste, j’adore la console Scaleway (Elements donc), je voulais le dire. C’est fait. On peut y aller maintenant. Chez AWS, j’avais pour mes outils personnels et mes devs foireux une “instance à tout faire” : Image Region/AZ Instance vCPU RAM Volume Price Ubuntu 20.04 eu-west-1 t2.small 1 2 GB 12 G €18.60/month Chez Scaleway, pour mon instance perso principale, il me faut un peu plus.

En avant chez Scaleway !

Depuis quelques temps, j’envisage de dégager une partie de mon infrastructure personnelle (voire même toute) chez un hébergeur français/européen. Le titre a tué le suspens, j’ai choisi Scaleway. L’objectif : ne rien perdre en cours de route, que ce soit en service ou en fonctionnalité. Notez que Scaleway, c’est trois branches différentes: Scaleway Elements : leur écosystème de cloud public. Scaleway Dedibox : on ne le présente plus, c’est l’ancien online.net, fournissant des serveurs dédiés, du nom de domaine, du stockage. Scaleway Datacenter : on connait un peu moins, c’est leur division purement housing. La première étape, c’est d’inventorier.

Installer/configurer Google Cloud SDK sur Debian

Google Cloud dispose, comme AWS, d’une API plutôt très bien fournie. Sur cette API s’appuient plusieurs librairies et outils, dont le plus utilisé est Google Cloud SDK. Ce dernier comprend, entre autres, les outils de ligne de commande gcloud, gsutil et bq. Aujourd’hui je vous propose un petit tuto sur comment installer, puis configurer l’outil gcloud pour manager vos ressources dans le cloud de Google. En premier lieu, il vous faut créer un projet via la console Google Cloud. Cette étape est primordiale car vous ne pourrez pas configurer proprement gcloud sans projet : dans Google Cloud tout se joue dans ceux-ci.

L'interprétation de dpkg --list

dpkg est, comme tous le savent, un formidable outil de gestion des paquets sous les distributions GNU/Linux bien connues Debian, Ubuntu mais également d’autres, qui d’ailleurs sont basées souvent sur l’une des deux. On discutait hier avec l’ami Carmelo des statuts des paquets que nous donne la commande dpkg -l ou dpkg --list. J’en connaissais 2 ou 3 mais je me suis rendu compte que je ne m’étais jamais intéressés aux autres, donc j’ai creusé un peu les manpages et je partage le résultat de mes recherches ici. Un paquet listé par dpkg -l est défini par deux composantes qui sont les deux lettres sur les deux premières colonnes de la sortie de la commannde.

Perl 7, WTF ? (et aussi, yeaaaah :))

Rapidement abordé sur l’édito précédent, une news de fou pour les perleux du monde entier a pointé le bout de son nez le 24 juin 2020 sur le site officiel du langage Perl. Announcing Perl 7 Et là, on s’est tous dit : mais wtf, Perl6 a déjà été tenté et s’est avéré être un échec (pour les perleux), principalement à cause du changement de philosophie majeure et de la cassure au niveau rétrocompatibilité. Snif, pour un langage qu’on a attendu 10 ans. D’ailleurs, Perl 6 est tellement différent en terme de … Bah en fait, tout, qu’il a été renommé Raku pour bien casser le lien.