AncalagonTotof a écrit 455 commentaires

<troll>Dite, vous n'avez pas l'impression que c'est un étudiant qui nous fait faire son boulot ?…</troll>

• Côté client : ssh -X ... <user>@<host> (ou -Y; là de tête, je ne me rappelle pas la différence)
• Côté serveur : virt-manager

À la condition de pouvoir installer virt-manager sur le serveur.

mais peut-être pas en NTFS

Alors juste pour la petite, et vieille, histoire …
Il y a 15-20 ans, quand j'étais obligé de bosser sous Zindoz, j'utilisais beaucoup Cygwin.
Et un jour, le déclic !
ln ou ln -s dans un shell Cygwin !
Et tenez-vous bien, ça marche !
Si.
Y'a même un petit icône, une petite flèche, que j'avais jamais vu qui apparaît sur celui du fichier.
OK.
Bien.
Mais seulement pendant un certain temps.
Je peux pas dire mieux.
Je sais plus ce que devient ce lien (il disparaît ou devient une copie ?).
Mais ça ne dure pas.
C'était trop beau.
Mais c'est Zindoz, hein, faut pas trop en demander …

Temps de réponse normal seul ou quand tout le monde ne fait qu'éditer du code.
Lamentable quand une ou plusieurs compilation de grille écran ou de code sont en cours.
Rien à voir avec la liaison entre les vieux terminaux et l'AS400, largement assez rapide.

Au passage, séquence vieux con : le terminal ressemblait à ça. Le clavier était magique, à peu près au niveau de sensation d'un modèle M.
Mais il fait un bruit d'enfer, facilement désactivable.
En effet, il suffisait de passer un doigt par une ouverture à l'arrière pour attraper les fils de l'électro-aimant.
Oui, un électro-aimant ! Appuis sur une touche = électro-aimant qui attire une plaque de métal qui fait un gros "clac" !

Yep, ça existe, mais là, c'est un ancien magasin reconverti.

D'accord, sauf pour le casque ! Dans un open space de >600 personnes, sans, tu deviens dingue …

Le rapport signal/bruit du COBOL est à peu près le même que celui du XML …

Pour les plus jeunes : qui est Higgins …

Attention, pas mal de n'importe quoi et de +/- hors sujet dans le sujet ! Et je ne préviendrai pas quand ça tiendra du troll …

La dernière fois que j'ai fais du COBOL, c'était en 1990 en TP à l'IUT, sur l'AS400 tout neuf. Souvenir de souffrances … Tout neuf, mais sous dimensionné : parfois 30 secondes entre l’appui sur une touche et l'apparition du caractère dans le code. Compilation de code et de "grilles écran" longues, très longues ! OK, c'était probablement l'entrée de gamme, trop faible pour gérer 12 terminaux en parallèle dans la salle de TP. Wait ! 12 ??? Seulement ???

De nos jours, l'AS400 existe encore. Je ne sais pas si c'est programmé en COBOL, mais dans de nombreux cas, un vendeur d'une grande enseigne réalise ses ventes en faisant apparaître une magnifique "grille écran" dans une fenêtre Windows 10 ! Quel décalage …

Je ne dis pas que ces vieux systèmes sont à cramer ! Un pote a bossé sur du Bull dans les 90/2000, et il me vantait souvent la puissance de l'espèce de BASIC très orienté gestion et super adapté au tâches demandées.

Et puis Java est arrivé ! Et les écoles ont commencé à pondre des cohortes de "p'tit jeunes" pisseurs de lignes et de grand principes et adeptes de "t'as vu la dernière techno machin, tout le monde en parle". Hein ? Quoi ? Ça fait plus de 15 ans que je code à l'aide de Qt & C/C++, et je suis loin d'en avoir fait le tour, très loin. Minute quoi !

Là, j'ai essayé de m'y mettre, à Java, quand même un peu, mais j'ai toujours du mal. Mon job étant plutôt dans la prog proche du système et embarqué, j'ai pleuré le jour où on a essayé de faire un projet en Android Things. Tous les types sont signés, aucun non signé ! Comment gérer des octets proprement en Java quand le type byte est signé ? Facile, y'a qu'à utiliser la taille au dessus sur 16 bits ! Et puis déployer des trésors de calculs inefficace pour faire les conversions ! On a abandonné quand l'appli commencé à crasher juste parce qu'elle était trop gourmande en RAM. Aucun contrôle pour empêcher ça.

Dans un autre registre, le même pote a changé de boite, et il a vu passer quelques perles. La plus belle : un batch journalier qui prenait plus de 24 heures. Batch en Java … Bah oui, fallait faire du SQL dedans. Avec une requête à 900 niveaux de parenthèses. 900 ! Oui, c'était fait par un générateur de requête. Mais les mecs ne se posent plus la question des ressources, est-ce que je pousse pas un peu le bouchon, ça pourrait pas être un poil optimisé …
Ça lui est arrivé plusieurs fois de faire concurrence aux p'tits jeunes codeur Java sur du traitement de fichier texte. Encore une fois, ils sortent leur Java là où un peu de script ou de awk va des dizaines ou des centaines de fois plus vite.

Et puis y'a ma boite, plutôt grosse, avec plein de magasins en France, un site Web qui doit être remplacé, il y a deux ans … Ouais, deux ans de retard pour passer des vieilles technos "moches" sur AS400 (plein et des gros qui vont assez vite ici) à un empilement de dizaines de techos et d'outils gérés par 10 % d'internes et 90 % d'externes. J'ai eu l'occasion de voir le taf d'un type du "back" et d'un autre du "front" : il leur faut un site avec les liens vers chacun des outils utilisés. Au moins 20 ou 30 sur le premier. Sinon, impossible de se rappeler de tout.
Et pour avoir bien merdé sur notre petit projet Android Things au niveau de la gestion des versions de dépendances, je n'ose pas imaginer la fragilité du château de carte sur lequel ce site Web doit reposer !

OK, j'ai bientôt fini de vider mon sac n'importe comment. Mais ce qui me fait peur, c'est l'empilement monumental de techno non maîtrisée, consommatrices de ressources machine et humaine, avec des humains qui ne se préoccupent pas de la prod parce qu'ils sont con à la prod, franchement, ils pourraient mettre des machines qui tournent plus vite et plus de serveurs.

Mais bon, qui suis-je pour aborder ces sujets quand mon quotidien est plus proche d'un micro-contrôleur … Je serais plutôt une vieille casserole, parmi les vieilles marmite, et qui avait envie de vider son sac …
En plus, il existe MicroEJ sur micro-contrôleurs …

Ou, en plus court, cette loi arrive ou revient parce que la police a des choses à cacher.
Ne serait-ce que le travail de David Dufresne.

T'as pensé à un TV ? HDMI & audio du coup.
Et puis, ça conserve l'esprit de l'engin : un ordinateur personnel tout en un à brancher sur le TV familial ! Comme mon ZX81 …

Sur mon Machinetoc Livre Pro de fin 2013, la RAM est déjà soudée, mais le SSD peut-être remplacé.
Sur les modèles qui ont suivit rapidement, même le SSD est soudé.

Autre exemple de "malfaisance" : Louis Rossmann a de millions de raisons de se plaindre de Apple. Parmi elle :

• jusqu'à une certaine génération, il sait que le Mac peut refuser de démarrer, il sait pourquoi, une puce décide de mourir toute seule, et il peut rapidement confirmer qu'elle est coupable et la remplacer (pour moins de $100 il me semble).
• sur les générations suivantes, même principe, quasiment la même puce, même problème de mort subite, mais approvisionnement impossible.

Évidemment, dans les deux cas, Apple propose un changement de carte mère (et donc de RAM et de SSD maintenant) à un prix prohibitif, pour pousser les gens à prendre une machine neuve.

Ajoutez à ça le problème de la puce T2, censée assurer la sécurité :

• un Mac "réparable" par simple remplacement de cette puce implique la perte totale des données. Tout fonctionne sauf la T2. Les données sont intacte. Mais le Mac ne démarre plus à cause de la T2. Un remplacement de T2 rend les données inexploitables
• un Mac d'occasion, protégé par cette T2 peut en fait être totalement brické si l'ancien proprio ne communique pas le mot de passe.

Il vaut mieux être averti quand on s'aventure dans cette voie. Les Mac ont certains avantages, et certains défauts aussi. Et c'est pas toujours mieux que chez la concurence, loin s'en faut.

Oulala, ça n'a pas l'air simple au niveau humain.
Bon, est-ce qu'on peut faire la supposition suivante ? Vu que

J'écris ce logiciel en Qt5/C++ pour avoir une interface graphique

donc au moins une personne est assez qualifiée pour coder une sorte d’interpréteur et toutes les "actions" découlant de l'interprétation des commandes du fichier ?

Ça suppose de ne pas pousser le bouchon trop loin, par exemple : pas de vérification de syntaxe ou pas trop poussée.

Partant de là, il est assez simple de lire un fichier ligne par ligne grâce à Qt. STFW si je peux me permettre : des choses autour de QFile, readLine (de tête).
Ensuite, pour chaque ligne, un .split(" ") par exemple, pour séparer en "mots".

Après, oserais-je dire : yapuka ?

Direct +1 !

Idéalement, c'est certain, il te faudrait une IP fixe.
Mais en attendant, si tu utilises DynDNS, tu vas toujours être vu comme un client de fournisseur d'accès.
Un moyen d'apparaître (plus) légitime serait de passer par le smtp de ton fournisseur d'accès.

Pour un postfix et chez Free, dans /etc/postfix/main.cf, ça serait relayhost = smtp.free.fr

Remarque, c'est valable même en IP fixe. Le soucis, ce sont les adresses listées comme appartenant à un FAI, qu'elles soient fixes ou pas.

Encore mieux : prend toi un domaine. C'est ce que j'ai fait récemment. J'ai regretté tout suite … de ne pas l'avoir fait plusieurs années auparavant !
Ceci dit, assure toi de pouvoir utiliser un ddclient ou un équivalent avec le service auquel tu souscris : ce ne sera plus chez DynDNS mais chez OVH, Gandi ou autre que tu devrais mettre à jour ton IP.

Et la couleur ???

Pas très utile : parce que c'était en début d'année, j'ai pas eu le temps d'investiguer et de corriger le problème. J'étais pressé d'installer une bécane qui "marche", du coup, je suis passé de la Debian à la Devuan de l'époque.

Problème :

• machine physique, pas dernier cri, dans les 5 ans d'âge
• objectif : espion réseau, avec deux cartes réseau et du NAT. Un côté réseau #1 "normal", un côté réseau #2 "espionné"
• installation from scratch de Debian Buster
• début de configuration : (tentative d') arrêt du client DHCP réseau #1, et remplacement par une IP fixe
• bug : IP fixe OK, client DHCP qui continue de récupérer une IP
• résultat : 2 adresses IP sur le côté réseau #1 + juron "c'est quoi ce bordayl, rend moi le contrôle de ma bécane ?"

Tentatives rapides : parmi les quelques trucs plus ou moins bricolo que j'ai tenté, j'ai tapé dans /etc/network/interfaces, j'ai essayé de piger si NetworkManager ou systemd emme^Wembêtaient leur monde, arrêt du N.M., désinstallation du N.M. Du bien bourrin qui n'a rien donné.

Solution d'urgence : Devuan à la place de Debian.

Résultat : comme attendu, zéro problème en Devuan, le système a fait ce que je lui ai demandé à la première modification de /etc/network/interfaces (ce qui n'est en rien bricolo en fait).

Voilà voilà. J'avais prévenu que ça ne serait pas très utile.
J'avais pas prévenu que c'était pour dire du mal de systemd …

Exact, ifconfig n'est pas dans le PATH d'un utilisateur lambda de Debian, mais il l'est dans celui d'un utilisateur Ubuntu par exemple (la dernière fois que j'ai essayé).
Plus important que le PATH, c'est la gestion des permissions, le contrôle du UID/GID par l'application, etc.
Accessible par défaut ou pas, M. Lambda ne pourra pas faire la même chose que root.

0) des fois que tu serais passé à côté : trouve un éditeur qui préserve les tabulations. Quand on écrit du code source, on bannit les tabulations généralement, mais dans un Makefile, c'est indispensable de les préserver. Je dis ça juste pour être certain de pas passer à côté.

1) pas beaucoup de réponse, certes. Je me demande si on est pas tous démangés par un RTFM … En moins méchant, il y aurait ça makefile tutorial
Le tuto que tu as trouvé n'est pas trop mal, mais un peu aride. La syntaxe des Makefile est tellement vaste que ça n'est pas sur un seul résultat de recherche que tu apprendras tout. Évidemment, c'est mieux de savoir produire un exécutable à la main pour comprendre l'intérêt de l'automatisation par Makefile (même si make peut servir à plein de chose qui n'ont rien à voir avec la production d'exécutable).

2) essaye ça :

-n, --just-print, --dry-run, --recon
     Print the commands that would be executed, but do not execute them (except in certain circumstances).

Ça pourrait t'afficher ce qui se passe sans le faire réellement. Cf point suivant pour l'usage du conditionnel.

3) ça fait longtemps, très longtemps, que je n'ai pas écrit un Makefile à la main. Le plus souvent, j'utilise Qt et son qmake, un générateur de Makefile, à partir d'une description plus simple du projet. Il existe plein d'autres solutions, mais c'est quand même bien de savoir comment fonctionne un Makefile, en cas de pépin, ça permet d'en trouver la cause.

4) pratique, teste, essaye, bricole. Ce genre de trucs ne vient qu'avec le temps. Quand j'ai vu make, awk et cie à la fac, j'ai pas pigé l'intérêt par rapport à la complexité. Maintenant, je ne peux plus m'en passer et je trouve ça simple. L'expérience ne peut pas venir en 5 minutes.

Je crois qu'il ne faut pas chercher plus loin. Change de clé. Et mets l'autre dans la bonne poubelle.

Dans la deuxième étape, pourquoi passer par

dossier=$DEST/`dirname "$fichier"`

?

Est-ce que

touch "$DEST/$fichier"

fait l'affaire ?
(avec les guillemets en plus)

D'ailleurs, à la réflexion, un

echo touch $dossier/$fichier

devrait afficher des chemins pour le moins troublants …

1. badblocks : je ne l'utilise jamais, et pourtant, il est recommandé de faire une passe de badblocks sur un disque neuf. Pourquoi je ne le fais pas ? Ça prend l'éternité ! Et c'est long, surtout vers la fin ! (je vois que ça n'est pas que de Desproges, loin de là)
2. smartctl : pour afficher l'état S.M.A.R.T. du disque. Généralement smartctl -a /dev/sdx. On y trouve énormément de chose, dont le nombre de secteurs réalloués. Cet indicateur, quand il augmente régulièrement (ou chaotiquement !) est le signe que ça urge : backup et remplacement.
3. testdisk et photorec : quand il est déjà trop tard …

Des trucs comme Munin ou Netdata (et plein d'autres) permettent de monitorer une bécane, y compris au niveau de l'état des disques.

Après, dit toi bien une chose : c'est rare qu'un disque dure longtemps. Pour certain, longtemps, c'est +/- 10 ans. 5 à 7, c'est déjà pas mal.
Pour Seagate, c'est souvent moitié moins, voire pire …
Je suis resté trop longtemps chez Seagate, et je me retrouve avec une flopée de disques bancals. Je ne peux plus les utiliser 24/7. Mais ils ne sont pas encore morts. À côté, un bon paquet a sérieusement déconné, en particulier la série 7200.11, mais pas que. Souvent après la fin de la garantie. Et Seagate ne remplace plus par du neuf, il retourne des disque réparés.
Il n'y a que les Baracuda XT en 3 To qui m'ont laissé une bonne impression. Ça tourne encore bien.

Depuis récemment, je roule en Western Digital. C'est plus cher, mais jusque là, ça tourne rond.

Tout à fait :

$ a | b

provoque la création de deux process, un pour a, un pour b, et l'utilisation de

int pipe(int pipefd[2]);

pour établir le lien entre la sortie de a et l'entrée de b.

Pas besoin de fork. D'ailleurs, en shell, fork n'existe pas en tant que tel (à ma connaissance).
Donc:

• soit tu y penses avant, et tu tapes :

$ monTruc.sh &

Et là, monTruc.sh s'exécute et tu récupères la main. Les sorties standard et d'erreur de monTruc.sh vont se mélanger à ce que tu continueras à faire dans ton shell libre de toute entrave.

• soit tu oublies, et, après coup, tu fais un <CTRL>+z, suivit d'un bg (pour background) :

$ monTruc.sh
^Z
$ bg

Le résultat est quasiment le même.
Un fg te permettra de remettre ton process au premier plan (foreground).

Surtout, monTruc.sh lancé en arrière plan ne pourra pas interagir avec ce que tu pourrais entrer au clavier (entrée standard)

De quel fork parles-tu ?

# man -k fork
fork (2)             - create a child process
forkpty (3)          - terminal utility functions
vfork (2)            - create a child process and block parent
vfs_aio_fork (8)     - implement async I/O in Samba vfs

De base, fork() s'utilise en C. La fonction clone le process courant, et retourne le PID du fils au père, et 0 au fils.

Tu parles de scripts ? Peut-être du & à la fin d'une commande ? Si c'est ça, ton problème pourrait provenir de l'emplacement de ce &, des guillemets ou quote manquant (" et ')

Donne un contexte un peu plus précis, ou des exemples.

On le sait fortement lié/dépendant/maqué à l'Europe (institutions, lobbies, etc). Mais là, ça me fait l'effet d'un texte qui viendrait d'un lobby justement :

Dans le soft, on ne doit dépendre d'aucune puissance (NdA : Y'a du boulot) mais européenne (NdA : ?!?).

Mauvaise re-traduction de mon cru trop tôt le matin : "In software, we must not depend on any power but European"

"mais" <--> "but" ?

Sinon, effectivement, y'a du boulot. Mais ça serait bien de commencer par ne pas filer du contrat sans appel d'offre ou Open Bar tout le tour du ventre à Micro$soft.