Et dans mon humble expérience, les rares fois où l'on est réduit à Vi brut de décoffrage en rescue mode, on arrive toujours à se démerder. (“Hé m***e c'est vrai y'a plus de :split ici”).
Je comprend, par contre ca me conforte dans l'idée que :x est plus intéréssant dans beaucoup de cas de figure.
L'edition simple d'une part, et de l'autre, on evite la demande de confirmation.
Merci pour les explications en tout cas :)
En relisant, je me dis que mon explication n'est peut être pas clair, du coup :)
“:x” ne sauvegarde que si le fichier a été modifié dans vi.
Donc dans l'exemple :
“:x” n'écrase pas le fichier, mais quitte simplement, comme “:q”.
“:wq” tentera d'écrire, et demandera une confirmation, puisque le fichier a été modifié hors vi entre temps.
Ya un timer sur le serveur du coup ça envoie une alerte avec les derniers logs envoyés par le client (processus, % d'utilisation du cpu, du cgu, users loggés…) s'il a pas reçu de notif depuis un certain temps :)
J'ai implémenté un algo de plus court chemin via la méthode de Dijkstra et celle de Bellman pour les cours, et je suis en train de créer un logiciel de visualisation de l'état de machines sous linux (le serveur est réalisé sous flask, première fois que je touche à un truc comme ça :D) et les sondes sont en bash et envoient les infos via wget. C'est rigolo :)
Hum; interessant ce point, donc, imaginions la chose suivante :
vi /var/log/syslog
[2min se passe … des lignes sont rajouté dans dans le syslog]
si à ce point là, je fais :x (ce qui biensur, est assez couillon, tout autant que le :wq) je n'aurais PAS les lignes rajoutées ?!
J'ai continué à bosser sur un site de vente de vidéos pégagogiques en ligne.
Et là depuis hier je migre toutes les machines du lycée privé de Saint-Hippolyte-du-Fort (un routerboard, deux serveurs, vingt postes clients) vers CentOS 7.
Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose.
(attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)
J'ai créé ma première web app Weblocks ! Un framework Common Lisp (je continue à creuser la question, ça marche toujours…) qui permet d'écrire une app dynamique totalement en CL, une sorte de React mais plus côté serveur. Le but est d'avoir un bon environnement de dév pour back&front, de ne pas mélanger les languages, de créer un exécutable (et déployer facilement, sans pip, npm, docker…), de résoudre “le problème javascript” (et son écosystème), de développer avec un bon REPL, d'avoir un language plus flexible que python ou JS, plus typé, etc.
La HP Prime supporte aussi Python (avec un firmware officiel récent, voir https://youtu.be/NjZwKW78D_M?t=2m18s ). Personnellement, je trouve ça horrible d'écrire du Python avec si peu de touches; et surtout l'indentation sur un petit écran, ça tue !
Que dire de plus !?! Bravo
C'est fait :) Merci pour le soutien ;)
Ils se sont rendus compte qu'il y a pas vraiment de pare-feu dans OpenOffice, du coup ça les intéresse moins. :o)
Sinon, le meilleur formateur pour Vim, c'est Vim lui-même.
https://blog.microlinux.fr/vim/
Et dans mon humble expérience, les rares fois où l'on est réduit à Vi brut de décoffrage en rescue mode, on arrive toujours à se démerder. (“Hé m***e c'est vrai y'a plus de :split ici”).
Cet article mentionne cette association https://www.automotivelinux.org et la met sur le même pied d'égalité que la fondation Linux.
Lors du Fosdem 2017, j'avais découvert cette fondation très active autour de l'informatique embarquée dans l'automobile.
Voilà une piste pour lever un peu de tes doutes :-).
J'ai commencer a developer un jeu vidéo sur Unity3D ! C'est un jeu d'arcade en 2D. Le project avance bien :)
Je comprend, par contre ca me conforte dans l'idée que :x est plus intéréssant dans beaucoup de cas de figure. L'edition simple d'une part, et de l'autre, on evite la demande de confirmation. Merci pour les explications en tout cas :)
En relisant, je me dis que mon explication n'est peut être pas clair, du coup :) “:x” ne sauvegarde que si le fichier a été modifié dans vi.
Donc dans l'exemple : “:x” n'écrase pas le fichier, mais quitte simplement, comme “:q”. “:wq” tentera d'écrire, et demandera une confirmation, puisque le fichier a été modifié hors vi entre temps.
Ya un timer sur le serveur du coup ça envoie une alerte avec les derniers logs envoyés par le client (processus, % d'utilisation du cpu, du cgu, users loggés…) s'il a pas reçu de notif depuis un certain temps :)
Marrant de faire ça dans le sens Client => Serveur Et si le client n'est pas en capacité d'envoyer?
J'ai implémenté un algo de plus court chemin via la méthode de Dijkstra et celle de Bellman pour les cours, et je suis en train de créer un logiciel de visualisation de l'état de machines sous linux (le serveur est réalisé sous flask, première fois que je touche à un truc comme ça :D) et les sondes sont en bash et envoient les infos via wget. C'est rigolo :)
L'année du postes client Linux??
Hum; interessant ce point, donc, imaginions la chose suivante :
vi /var/log/syslog[2min se passe … des lignes sont rajouté dans dans le syslog] si à ce point là, je fais :x (ce qui biensur, est assez couillon, tout autant que le :wq) je n'aurais PAS les lignes rajoutées ?!
Il y a une très légère différence entre les deux : “:wq” sauvegarde, puis quitte. “:x” sauvegarde si le fichier a été modifié, puis quitte.
Dans le cas où le fichier a été modifié par une autre application entre temps, le résultat final sera différent ;)
plutôt les PCs sous Debian :)
c'est bon ça !
J'ai continué à bosser sur un site de vente de vidéos pégagogiques en ligne.
Et là depuis hier je migre toutes les machines du lycée privé de Saint-Hippolyte-du-Fort (un routerboard, deux serveurs, vingt postes clients) vers CentOS 7.
Est-ce bien compatible VI (et non VIM) ?
Perso, je ne comprend pas les gens qui retienne “:wq” quand on peut faire “:x” qui fait la même chose. (attention, “:w” ou ‘:q" tout seul, okay, mais les deux :s)
J'ai créé ma première web app Weblocks ! Un framework Common Lisp (je continue à creuser la question, ça marche toujours…) qui permet d'écrire une app dynamique totalement en CL, une sorte de React mais plus côté serveur. Le but est d'avoir un bon environnement de dév pour back&front, de ne pas mélanger les languages, de créer un exécutable (et déployer facilement, sans pip, npm, docker…), de résoudre “le problème javascript” (et son écosystème), de développer avec un bon REPL, d'avoir un language plus flexible que python ou JS, plus typé, etc.
C'est très bêta.
La HP Prime supporte aussi Python (avec un firmware officiel récent, voir https://youtu.be/NjZwKW78D_M?t=2m18s ). Personnellement, je trouve ça horrible d'écrire du Python avec si peu de touches; et surtout l'indentation sur un petit écran, ça tue !