-
Avec CoreOS, je ne me pose plus la question ^^
-
bersace il y a 5 ans | lien | sur : Créer une newsletter personnalisée avec les services cloud AWS et ElasticSearch
Beuark. Pierre a-t-il déjà administré un ElasticSearch en prod pour utiliser ce gros bouzin pour faire un OU binaire ? DynamoDB ne sait pas faire d'Index pour avoir besoin d'ES ?
Exemple parfait d'archi qui, sous couvert de consommation à la demande, consomme énormément d'énergie pour le résultat obtenu.
-
Mettez
#!/bin/bash -euet sauvez un chaton d'une mort effroyable !-
Une petite explication du pourquoi ?
-
-edé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.-uchange 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.-euest en quelque sorte le mode strict de bash, pour reprendre une terminologie de PHP. Autant, en interactif,-eusont inutilisables, autant dans un scripts ils me semblent indispensables.-
Merci pour l'explication complète :)
-
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.
-
-
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.
-
Ça sert à « inverser » le code de retour
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.
-
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.
-
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.
-
-
-
-
-
-
-
-
-
On est en plein dans le règne de la pensée computationnelle. Tout doit pouvoir être prédit par une formule mathématique. L'apprentissage machine permet de se passer de résoudre les équations, il suffit de conjecturer à partir de l'existant.
-
Comment gère-tu l'installation de logiciel et l'édition de fichier existants ?
-
-
C'est énorme ! Bravo Tristan !
J'utilise Qwant sur mobile, c'est très bien. Sur mon poste c'est DuckDuckGo. Je pense que mélanger les moteurs est une bonne idée, non ?
-
Impressionnant, je ne connaissais pas. Ça a l'air de remplacer avantageusement minikube pour le dév !
Et notamment, est-ce qu'on peut monter un dossier local dans un pod, histoire de développer dans k8s comme on développe avec docker/docker-compose ?
-
-
Dans le cas du dév, l'idée est de monter un dossier dans un service (au sens compose), je pense que ça correspond à Pod dans le vocabulaire k8s.
À ta réponse, j'ai l'impression que tu veux monter le volume dans le cluster. Peut-être est-ce nécessaire pour monter ensuite le volume dans le pod ?
Quand tu dis docker-in-docker, cela signifie juste que /var/run/docker est monté dans le conteneur, n'est-ce pas ? k3s ne lance pas un deuxième dockerd dans son conteneur, j'espère !
-
Il faut monter le volume dans le cluster pour effectivement pouvoir monter dans le pod ensuite, car c'est bien du docker-in-docker, tu as un daemon docker interne, pas de montage de socket de l'host. Pour les conteneurs tournant dans le cluster, les hosts sont les conteneurs que tu voies depuis ton laptop. C'est perturbant mais pas tellement gênant au final, il faut juste penser qu'il y a un intermédiaire si tu veux monter des volimes depuis ta machine physique.
-
-
-
-
-
Ça rappelle Le film “Le rapport minoritaire”, avec Tom Cruise. Avec les pubs contextualisée par le reconnaissance à distance de l'iris. Effrayant.
-
Le lien semble cassé. Il semble que le bon lien soit : https://www.nextinpact.com/brief/facebook-hermes--le-moteur-javascript-qui-veut-accelerer-react-native-9413.htm
-
-
Excellent article dans la presse générale, c'est rare ! Bravo à l'auteur et à FP pour le travail de communication.
-
Le propos me titille un peu, dans la mesure où ça tend à dé-responsabiliser les employeurs concernant leurs obligations vis à vis des travailleurs : « puisque de toute façon c'est leur santé qui est en jeu, ils vont bien y aller de leur propre poche ». Sauf que non, il y a des gens qui n'ont pas les moyens ou pas la connaissance. Et ça nous fait potentiellement des situations comme celle sur laquelle tu t'est appuyé.
-
-
Bien sûr, mais combien oserons porter plainte contre leur patron parce qu'il ne veut pas leur acheter un casque à 30 € ? Il ne faut pas se voiler la face, emmener son patron au prud’hommes c'est faire une croix sur sa carrière au sein de la boite (potentiellement couler la boite et se mettre à dos les autres employés), donc il faut changer de boulot derrière… et tout le monde n'est pas dans un secteur aussi porteur que l'informatique. Puis si un potentiel futur employeur apprend que tu envoyé ton précédent aux prud'hommes ça peut le refroidir quant à ton embauche.
-
-
Yo,
Je doute que ça dé-responsabilise les employeurs, l'article débute sur une affaire où l'employeur est condamné, je rappelle que “légalement et pénalement l’entreprise doit veiller à votre santé/sécurité et vous fournir le matériel adéquat pour exercer votre métier”. Après si c'est ton ressenti, je peux l'entendre.
Concernant la situation sur laquelle je me suis appuyé, je doute que ce soit un problème de moyens (30 euros) ou de connaissance (savoir qu'il faut un casque antibruits, comprendre qu'il souffre).
Tcho !
-
Oui l'employeur a été condamné, une fois que le mail était déjà fait et qu'on ne pouvait que le constater. Combien envoie leur employeur aux prud'hommes alors qu'ils sont encore engagés dans la boite ? Je te renvoie la réponse un peu plus développés que j'ai faite a bersace.
Puis 30 €, pour nous peut-être que ce n'est pas grand chose, on a les salaire et les cadres de vie qui permettent ce genre de comportement. Mais ceux qui sont désarmés par une baisse de 5 € des APL, tu vas leur dire d'acheter un casque à 30 € en attendant que leur exploiteur de patron se décide à obéir à la loi ? Je ne t'apprends rien en disant ça et je sais que tu en es conscient, mais la vie n'est pas si facile pour tout le monde.
-
Le SMIC net mensuel en France est à 1201 euros, la consultation chez un généraliste à 25 euros, le casque antibruits à 30 euros. N'importe quel salarié peut se payer un casque antibruits, j'ai pris cet exemple pour ça. Après c'est une question de priorités, le casque doit passer avant/après l'électricité, l'eau, le loyer, les courses, l'essence… ? C'est tout le sujet de l'article, où on place notre santé et faut-il débourser 30 euros (alors que c'est au patron de le faire) pour éviter de devenir sourd ?
Tcho !
-
-
-
-
Un bon exemple comme quoi le cloud troque des problèmes pour d'autres :-)
Ça fait bizarre de faire du préchauffage sur lambda pour les garder démarrée. Pourquoi ne pas utiliser EC2 ou EKS ?
-
Bravo aux mainteneurs de youtube-dl !!
-
Plus de 5 ans après Prism. La réaction se sera faite attendre ;-)
-
pour l'armée 5 ans c'est du court terme ;p
-
-
Pour ma part, je vois l'inverse. Le bureau Linux se restructure.
Effectivement, les installations sapins de Noël avec trouze millions d'outils incohérents avec chacun leurs dépôts, sont sur le déclin. De même que plus personne ne va rue montgallet acheter sa tour en pièces détachées. Les ordinateurs portables ont tué cela.
En revanche, avec une Debian + GNOME 3, j'installe le poste de madame ou de papa et j'ai la paix pour un moment. Et eux aussi. Ils ont même quelques applis proprios natives pour certains besoins spécifiques. Ils sont très heureux d'avoir un système aussi simple que leur téléphone. Pas de popups de partout, pas d'instabilité, pas de reboot avec 30 minutes de mises-à-jours, etc.
Alors oui, c'est d'autant plus confortable qu'on a moins de gadget dernier cri, incompatible avec la debian d'il y a deux ans. Il se trouve que ça rejoint notre souhait de plus de sobriété : plus de tablettes, moins d'écrans, etc.
Côté jeux, j'ai été bluffé de découvrir Lutris et la bibliothèque conséquente. J'ai aussi découvert OpenRA, une superbe implémentation d'Alerte Rouge. Il ont même réimplémenté le comportement agaçant des unités qui font des détours chez l'ennemi pour rentrer à la base !
Oui, les choses changent. Je ne trouve pas qu'un monde entre Google, Windows et Mac OS soit désirable. Quelle confiance leur accorder ??
Merci Debian, Red Hat, Canonical et les grandes entreprises qui jouent le jeu du libre et contribue un système dans lequel j'ai confiance !
-
Je suis relativement du même avis. GNU/Linux se structure, et s'ouvre de plus en plus, notamment avec les nouveaux format d'application flatpak, snap et/ou appimage, qui permettent plus facilement au entreprise créant du logiciel non libre et non opensource de partager leur application sur plusieurs distribution sans risque de compatibilité. Je suis pas fan de ces technos pour les applications natives, mais pour les applications proprio, pourquoi pas, si cela peux aider.
Les bureaux aussi s'améliore énormément, avec une intégration sans égal, notamment kde (j'aime pas, mais je l'ai testé il y a peu) qui permets de connecter pas mal de type de compte (nextcloud, google, outlook, facebook etc …), et d'y intégrer directement les contacts au gestionnaire de contact, et les évènements directement dans le calendrier système. Il me semble que gnome 3 le permets aussi. On arrive de plus en plus à une expérience utilisateur à la Android, avec une interaction entre les applications, manque plus qu'une API générique pour tout les DE, et c'est parfait.
Comme tu dis, coté jeux, c'est fou les améliorations qu'il y a eu en quelques temps, merci à DXVK (désolé j'ai pas le nom du dev) et Valve pour ça, maintenant y'a facilement 50% des jeux qui tourne aussi bien que sous Windows, certains même mieux. Avec Lutris qui simplifie énormément l'installation avec DXVK, c'est top. J'avoue que j'ai toujours un Windows 10 qui me sert 1 fois par semaine pour ma partie hebdomadaire de Rainbow Six ^^.
J'installe énormément de distribution GNU/Linux (principalement du Ubuntu et dérivés, Linux Mint et DeepinOS) pour des utilisateurs lamba (web, mail, jeux de carte etc …), et depuis j'ai rarement d'appels pour des trucs à la con, genre “j'ai ça qui me demande de mettre à jour”, “j'ai un message qui apparait” ou “Tu peux m'installer un truc”. Tout est centralisé, les mises à jours ne sont pas intrusives, elles se font, et tu redémarre quand tu veux.
Je pense que ce qui tue réellement GNU/Linux, c'est la vente lié, car beaucoup de personnes achètent encore dans des grandes surfaces (carrefour ou autre), et là tu n'as pas le choix, c'est Windows (même Mac est rare). Attention, je ne dis pas que si GNU/Linux était vendu dans les grands surfaces il aurait 50% de part de marché, mais je pense qu'il pourrait atteindre un bon 10% pour se mettre au même niveau que Mac OS.
-
-
Beurk le wget des sources dans debian/rules :( Il y a debian/watch pour ça.
-
Je trouvais le titre pompeux, mais à la lecture, j'ai vite trouvé cet article pleins de bon sens. À partager !! Merci !
-
-
DEB n'aurait pas put être intégré dans LSB. C'est trop compliqué et deb-helpers bouge tout le temps. git-buildpackages, pbuilder, debuild, dpkg-packages, deb-helpers, etc. tout ça est trop compliqué. Sans parler du simple fait qu'un paquet source debian est constitué de trois fichiers…
un .spec contient tout le dossier debian/. Les macros font bien le travail de deb-helper.
Les problèmes de dépendances ou de compatibilité peuvent également arriver sur un paquet debian si on écrit mal son rules, son control ou son changelog.
-
Rohhhhh le troll poilu … C'est plus simple de créer un package debian. J'avais même fait un outil pour générer des packages depuis un téléphone maemo qui ne dépendais pas de dpkg et des deb helpers …
Mais en effet si 3 fichiers c'est trop compliqué … Je comprends mieux la philosophie derrière journald …
-
-
kikinovak plus de 5 ans | lien | sur : Y a-t-il une forme d’anti-Redhatisme primaire dans le monde du libre?
J'utilise RHEL/CentOS depuis les versions 4.x, et avant ça j'avais même un bouquin “Linux Formation Visuelle” avec un CD-Rom de Red Hat 6.1, on parle pas de RHEL mais de Red Hat. RHEL et CentOS font certainement partie des distributions les plus ennuyeuses qui existent, et dans mon boulot, “ennuyeux” est une qualité recherchée. C'est du “no drama”, pas de mauvaises surprises, et le ton général sur la mailing list centos@centos.org me semble assez symptomatique d'un professionnalisme sobre. Quant au format de paquets RPM, ma foi, ça fait près de vingt-cinq ans qu'il existe, et tout admin qui se respecte se doit de le connaître. Curieusement, les formats de paquets semblent susciter les mêmes passions que les marques de moto ou les clubs de foot. Ma foi.
-
Je peux en dire autant sur n'importes quelles distributions sérieuses. Et pour le format de paquet RPM, quand on voit que redhat dit ne pas avoir les moyens de maintenir sa sécurité…
https://blog.fuzzing-project.org/52-Multiple-vulnerabilities-in-RPM-and-a-rant.html
-
Sinon, une autre bonne raison pour utiliser Red Hat et dérivées.
-
Honnêtement, SELinux est mal foutu. La rédaction de policy est une plaie. Le langage de description est mal documentée et la foultitudes de macros en fait un énorme spaghetti. Ce faisant, je reconnais que le module noyau fait le travail. Je le met plus au crédit des développeurs Linux qui ont fait leur boulot de chien de garde.
-
-
-
-
L'allusion à un ordre des développeurs est intéressant. Comment cela se concrétiserai ? Un syndicat ? Une profession réglementée ? Quels seraient les moyens d'actions ? Je ne vois rien de réaliste.