perso j'ai été dans des boîtes où les devs venaient régler le problème avec les ops lors de soucis en production.
Et pour faire contrepoids à cet argument, j'ai rarement vu un ops aller parler des problèmes de haute dispo ou des contraintes système aux devs, ce qui peut amener ensuite les ops à s'étonner du comportement de l'appli alors qu'il a rien fait pour en informer les devs. Sans parler de l'IT interne qui s'amuse parfois à mettre des bâtons dans les roues aux devs considérés comme immatures ou foufous (ce qui arrivent qu'ils soient, parfois aussi) alors qu'ils ont quand même un programme à livrer avec des contraintes de temps.
Je pense que ça marche dans les deux sens cette histoire.
Et au marketing c'est aussi le chaos ? Était il absolument nécessaire de remplacer voyages-sncf.com qui, après être la risée de tous les professionnels de l'IT, fonctionnait à peu près correctement par le ridicule oui.sncf (et sa pharamineuse campagne de lancement) ?
Est-ce un wiki dédié aux inventions, aux problèmes scientifiques pas encore résolus ? J'ai du mal à extraire l'idée concrète. À force d'être trop dans le concept, d'y aller de manière trop nébuleuse avec un gros mediawiki avec des schémas partout, on est vite perdus. Ça explique sûrement le faible nombre de réactions sur linuxfr. Pour avoir le support de la communauté, je crois qu'il faudrait simplifier et rendre plus compréhensible le tout.
Effectivement, comme le dit kikinovak, on peut créer un /etc/vim/vimrc.local pour avoir une configuration spécifique globale, ou comme dit dans les commentaires de l'article, on peut aussi mettre ce qu'on veut dans le ~/.vimrc pour avoir une configuration spécifique à un utilisateur. Dans tous les cas, dès qu'il est possible de ne pas toucher les fichiers gérés par les paquets, je ne les modifie pas. Ça permet d'éviter des conflits lors de mises à jour, ou simplement de regrouper ses modifications spécifiques pour les retrouver plus facilement. En cas de problème après une mise à jour, c'est plus facile de désactiver tout ce qu'on a changé d'un coup pour voir si le problème vient de nos modifications : il suffit de renommer le fichier spécifique.
Pour détailler ce qui se passe : Avant Debian 9, le support de la souris n'était pas activé par défaut, donc la sélection faite à la souris était faite par l'émulateur de terminal. Maintenant, le support de la souris est activé dans vim, et donc c'est vim qui capture les événements de la souris : La sélection est maintenant faite par le visual mode de vim.
La solution de désactiver le support de la souris dans vim est simple, mais pas idéale. On peut aussi sélectionner avec shift+clic, pour forcer l'émulateur de terminal à gérer la sélection, sans désactiver le support de la souris de vim.
Dans ces deux cas, la sélection prendra en compte les numéros de lignes, marques de folding, etc. si c'est activé, ce qui est loin d'être idéal.
Une autre solution est d'utiliser le support du clipboard de X dans vim, avec "y une fois le texte sélectionné (en visual mode, évidemment, c'est vim qui doit gérer la sélection dans ce cas).
Si mon souvenir est bon, sous Debian et dérivées il suffit de créer un fichier /etc/vim/vimrc.local pour la config perso, ce qui évite qu'elle se fasse écrabouiller par une mise à jour.
Sur ma KDE neon (dérivée d'Ubuntu) ça ressemble à ça.
Merci pour ton retour ! Je vais essayer de corriger ça ce soir !
Concernant docker, j’ai préféré ne pas trop détailler car docker n’étais pas le centre de l’article, et concernant LXC ça date de 2014 et je ne l’ai meme pas vu passer… Encore merci et bonne soirée !
Sympa Portainer, il faudrait que je teste un de ces jours.
Par contre quelques imprécisions au sujet de Docker :
Plus simplement, il permet contrairement à une machine virtuelle, de créer un conteneur sans système d’exploitation, en incluant seulement l’application à exécuter.
En fait il y a toujours un système d'exploitation sous-jacent, à savoir le noyau de l'hôte et les libs de l'image de base choisie (ex : ubuntu:xenial, alpine:latest, etc.). Mais du point de vue de l'utilisateur du conteneur, il fait effectivement abstraction de la distribution sur laquelle il est construit et tourne (comme tous les conteneurs en fait).
La particularité d'un conteur Docker (dit « applicatif ») vis-à-vis d'un conteneur système (comme ceux de LXC ou OpenVZ), est qu'au lieu de lancer un système entier via un système d'init (typiquement systemd) et tou ce qui va avec, il lance juste son application.
Les conteneurs créés avec Docker sont basée sur le système d’exploitation de l’hôte et sont utilisés avec LXC notamment.
Comme dit dans les commentaires, il vaut mieux modifier son propre vimrc plutôt que le fichier defaults.vim qui sera écrasé à la prochaine mise à jour.
Les manpages disent ça à propos de mouse :
The mouse can be enabled for different modes:
n Normal mode
v Visual mode
i Insert mode
c Command-line mode
h all previous modes when editing a help file
a all previous modes
r for |hit-enter| and |more-prompt| prompt
Normally you would enable the mouse in all four modes with:
:set mouse=a
When the mouse is not enabled, the GUI will still use the mouse for
modeless selection. This doesn't move the text cursor.
See |mouse-using|. Also see |'clipboard'|.
Note: When enabling the mouse in a terminal, copy/paste will use the
"* register if there is access to an X-server. The xterm handling of
the mouse buttons can still be used by keeping the shift key pressed.
Also see the 'clipboard' option.
L'idée de ce contournement apparemment, c'est donc de désactiver le support souris sauf pour les prompt. Du coup le copier/coller (par exemple en mode insertion) fonctionne à travers le « relais » de l'émulateur de terminal. Mais ça ne nous aide pas à comprendre pourquoi depuis Debian 9 ça ne fonctionne plus. D'après ce que je comprends, vim ne peut plus accéder au clipboard Xorg ?
Les manpages font référence à Xorg, peut-on espérer un jour des adaptations pour copier-coller avec Wayland en ayant le mode souris activé ?
Le dashboard de mon bot discord avec NodeJS [ExpressJS] et Postgresql comme base de données
De temps en temps sur mon bot
Et je ne sais pas si c'est cette semaine que je ferai, mais je compte aussi refaire le thème de mon blog. Je vais peut-être monter un service Lut.im pour un usage perso sur une nouvelle machine chez moi ^^
Un chouette article ! Je me régalais à chaque fois que je lisais des articles qui crachent sur PHP, parce que ce sont souvent des articles peu argumentés et rédigés sur des vieux blogs Wordpress (pour le côté « cohérence »). On dirait que l'effet de mode du php-bashing s'est calmé. C'est bien, car PHP peut vraiment être un excellent outil, selon ce que l'on veut faire. Je trouve la conclusion très bonne : « En tant que développeur, il est important de choisir le bon outil en fonction de la situation, et de ne pas chercher à utiliser encore et toujours le même langage quelque soit la situation. »
Mageia, finalement c'est juste une distrib en grosse perte de vitesse. Si elle peut remonter la pente elle le fera, sinon elle s'éteindra et les efforts seront répartis dans d'autres projets libres. C'est normal, ça va pas m'émouvoir plus que ça.
Ce qui m'inquiète par contre, c'est la morandinisation de l'expression libriste francophone. On est dans une sorte de cocon, de microcosme où on dirait qu'on a rien à se mettre sous la dent alors on reprend une nouvelle un peu excitante (positive ou négative) pour la propager et donner son avis à chaud (ce qui est souvent risqué).
Je n'ai même pas imaginé que c'était voulu comme comportement… je me suis dit que peut-être l'un de me filtres anti-pubs faisait sauter le bouton de fermeture. Du coup j'ai ajouté la vidéo à mon filtre dans µBlock…
Sur les cgi-bin , si l'interpréteur est directement accessible, il est possible de lui injecter un programme, comme pour une ligne de commande.
Quant à Wordpress, les assets ne sont pas chargés, donc la supposition sur le DDoS est un poil fausse. Par contre, en cas de réponse position, on a un flux ininterrompu de tentatives d'accès.
À ce sujet, faites gaffe en mettant en place un honeypot, vous pouvez rapidement être noyé sous la quantité de tentatives d'intrusions, souvent avec des requêtes POST englobant des fichiers de plusieurs dizaines de mégas, originaires de dizaines de milliers d'adresses IP.
perso j'ai été dans des boîtes où les devs venaient régler le problème avec les ops lors de soucis en production.
Et pour faire contrepoids à cet argument, j'ai rarement vu un ops aller parler des problèmes de haute dispo ou des contraintes système aux devs, ce qui peut amener ensuite les ops à s'étonner du comportement de l'appli alors qu'il a rien fait pour en informer les devs. Sans parler de l'IT interne qui s'amuse parfois à mettre des bâtons dans les roues aux devs considérés comme immatures ou foufous (ce qui arrivent qu'ils soient, parfois aussi) alors qu'ils ont quand même un programme à livrer avec des contraintes de temps.
Je pense que ça marche dans les deux sens cette histoire.
tellement vrai
Sauf que … Quand y a un incident de production, on voit rarement le dev venir aider… jamais sa faute hein
l'éternel gueguerre sysadmin/dev… faut forcer les sysadmins à faire du dev et vice-versa !
Et au marketing c'est aussi le chaos ? Était il absolument nécessaire de remplacer voyages-sncf.com qui, après être la risée de tous les professionnels de l'IT, fonctionnait à peu près correctement par le ridicule oui.sncf (et sa pharamineuse campagne de lancement) ?
Est-ce un wiki dédié aux inventions, aux problèmes scientifiques pas encore résolus ? J'ai du mal à extraire l'idée concrète. À force d'être trop dans le concept, d'y aller de manière trop nébuleuse avec un gros mediawiki avec des schémas partout, on est vite perdus. Ça explique sûrement le faible nombre de réactions sur linuxfr. Pour avoir le support de la communauté, je crois qu'il faudrait simplifier et rendre plus compréhensible le tout.
Effectivement, comme le dit kikinovak, on peut créer un
/etc/vim/vimrc.localpour avoir une configuration spécifique globale, ou comme dit dans les commentaires de l'article, on peut aussi mettre ce qu'on veut dans le~/.vimrcpour avoir une configuration spécifique à un utilisateur. Dans tous les cas, dès qu'il est possible de ne pas toucher les fichiers gérés par les paquets, je ne les modifie pas. Ça permet d'éviter des conflits lors de mises à jour, ou simplement de regrouper ses modifications spécifiques pour les retrouver plus facilement. En cas de problème après une mise à jour, c'est plus facile de désactiver tout ce qu'on a changé d'un coup pour voir si le problème vient de nos modifications : il suffit de renommer le fichier spécifique.Pour détailler ce qui se passe : Avant Debian 9, le support de la souris n'était pas activé par défaut, donc la sélection faite à la souris était faite par l'émulateur de terminal. Maintenant, le support de la souris est activé dans vim, et donc c'est vim qui capture les événements de la souris : La sélection est maintenant faite par le
visual modede vim.La solution de désactiver le support de la souris dans vim est simple, mais pas idéale. On peut aussi sélectionner avec shift+clic, pour forcer l'émulateur de terminal à gérer la sélection, sans désactiver le support de la souris de vim. Dans ces deux cas, la sélection prendra en compte les numéros de lignes, marques de folding, etc. si c'est activé, ce qui est loin d'être idéal. Une autre solution est d'utiliser le support du clipboard de X dans vim, avec
"yune fois le texte sélectionné (envisual mode, évidemment, c'est vim qui doit gérer la sélection dans ce cas).Si mon souvenir est bon, sous Debian et dérivées il suffit de créer un fichier /etc/vim/vimrc.local pour la config perso, ce qui évite qu'elle se fasse écrabouiller par une mise à jour.
Sur ma KDE neon (dérivée d'Ubuntu) ça ressemble à ça.
https://github.com/kikinovak/kde-neon/blob/master/config/vim/vimrc.local
Merci pour ton retour ! Je vais essayer de corriger ça ce soir ! Concernant docker, j’ai préféré ne pas trop détailler car docker n’étais pas le centre de l’article, et concernant LXC ça date de 2014 et je ne l’ai meme pas vu passer… Encore merci et bonne soirée !
Sympa Portainer, il faudrait que je teste un de ces jours.
Par contre quelques imprécisions au sujet de Docker :
En fait il y a toujours un système d'exploitation sous-jacent, à savoir le noyau de l'hôte et les libs de l'image de base choisie (ex : ubuntu:xenial, alpine:latest, etc.). Mais du point de vue de l'utilisateur du conteneur, il fait effectivement abstraction de la distribution sur laquelle il est construit et tourne (comme tous les conteneurs en fait).
La particularité d'un conteur Docker (dit « applicatif ») vis-à-vis d'un conteneur système (comme ceux de LXC ou OpenVZ), est qu'au lieu de lancer un système entier via un système d'init (typiquement systemd) et tou ce qui va avec, il lance juste son application.
Docker n'utilise plus LXC depuis la version 0.9 : https://www.infoq.com/news/2014/03/docker_0_9
Comme dit dans les commentaires, il vaut mieux modifier son propre vimrc plutôt que le fichier defaults.vim qui sera écrasé à la prochaine mise à jour.
Les manpages disent ça à propos de
mouse:L'idée de ce contournement apparemment, c'est donc de désactiver le support souris sauf pour les prompt. Du coup le copier/coller (par exemple en mode insertion) fonctionne à travers le « relais » de l'émulateur de terminal. Mais ça ne nous aide pas à comprendre pourquoi depuis Debian 9 ça ne fonctionne plus. D'après ce que je comprends, vim ne peut plus accéder au clipboard Xorg ?
Les manpages font référence à Xorg, peut-on espérer un jour des adaptations pour copier-coller avec Wayland en ayant le mode souris activé ?
Pour moi c'est assez simple:
Et je ne sais pas si c'est cette semaine que je ferai, mais je compte aussi refaire le thème de mon blog. Je vais peut-être monter un service Lut.im pour un usage perso sur une nouvelle machine chez moi ^^
Suis du même avis !
Un chouette article ! Je me régalais à chaque fois que je lisais des articles qui crachent sur PHP, parce que ce sont souvent des articles peu argumentés et rédigés sur des vieux blogs Wordpress (pour le côté « cohérence »). On dirait que l'effet de mode du php-bashing s'est calmé. C'est bien, car PHP peut vraiment être un excellent outil, selon ce que l'on veut faire. Je trouve la conclusion très bonne : « En tant que développeur, il est important de choisir le bon outil en fonction de la situation, et de ne pas chercher à utiliser encore et toujours le même langage quelque soit la situation. »
PHP c'est juste moche… comme JavaScript d'ailleurs…
Python > All
Mageia, finalement c'est juste une distrib en grosse perte de vitesse. Si elle peut remonter la pente elle le fera, sinon elle s'éteindra et les efforts seront répartis dans d'autres projets libres. C'est normal, ça va pas m'émouvoir plus que ça.
Ce qui m'inquiète par contre, c'est la morandinisation de l'expression libriste francophone. On est dans une sorte de cocon, de microcosme où on dirait qu'on a rien à se mettre sous la dent alors on reprend une nouvelle un peu excitante (positive ou négative) pour la propager et donner son avis à chaud (ce qui est souvent risqué).
Je n'ai même pas imaginé que c'était voulu comme comportement… je me suis dit que peut-être l'un de me filtres anti-pubs faisait sauter le bouton de fermeture. Du coup j'ai ajouté la vidéo à mon filtre dans µBlock…
Sur les cgi-bin , si l'interpréteur est directement accessible, il est possible de lui injecter un programme, comme pour une ligne de commande.
Quant à Wordpress, les assets ne sont pas chargés, donc la supposition sur le DDoS est un poil fausse. Par contre, en cas de réponse position, on a un flux ininterrompu de tentatives d'accès.
À ce sujet, faites gaffe en mettant en place un honeypot, vous pouvez rapidement être noyé sous la quantité de tentatives d'intrusions, souvent avec des requêtes POST englobant des fichiers de plusieurs dizaines de mégas, originaires de dizaines de milliers d'adresses IP.
Finir mon cli pour vault