Reprise du message précédent :
J'ai essayé le soft que tu m'as conseillé Gatsu, ça fait 3 putain de journées qu'il tourne, je pense qu'il n'y a aucun espoir pour récupérer les données
 
https://i.ibb.co/94ThP3M/rawcopy.png

yavait pas des réglages possible (j'ai pas utilisé ce soft depuis longtemps c'est pour ça.
 
Va falloir finir avec du linux

La c'est ma nièce de 10 ans

clonezilla en mode "ignore les erreurs"

 
C'est pour ma station de travail.
 
J'ai un crédit de 1000$ pour m'équiper. J'ai déjà récupéré un fauteuil Steelcase correct à la fermeture des anciens locaux en janvier, donc j'ai pas besoin de grand chose.

Je sais pas pourquoi vos discussions me rappellent Louis CK: https://www.youtube.com/watch?v=_5jAUgJATAg
 
(et je débarque, mais il est revenu )

Fais pas ça pour l'argent. J'ai 2 personnes dans l'équipe qui gagnent plus que moi (et c'est normal).

Senior dans une grosse boîte ça touche plus que head of dans une petite, suffit de voir ce que G5 annonce (20k de plus que moi si tu veux un point de référence).

Sérieusement, ça fait des mois / années que tu es insatisfait professionnellement et que tu n'arrive pas à te cibler toi même. Vise ces postes si tu es persuadé que tu y seras bien et que tu le feras mieux que les autres, mais pas pour la thune ou l'ego / un pseudo statut social, ça ne te rendra plus heureux, au contraire.

 
Il me semble que c'est déjà le cas avec ce soft

- Avoir docker-engine qui peg mon CPU à 100% de temps en temps
 
OU
 
- Avoir podman-engine qui utilise mon CPU à 50% tout le temps
 

 
- ne pas bosser en local sous docker?

Tout l'intêret de docker-compose c'est quand même de monter une stack complète avec zéro conf
(Et surtout de pouvoir basculer entre deux profils facilement)
Le problème devrait plus se poser quand j'aurais mon Mac M2 mais en attendant  

Non
Enfin, je pensais pareil et les premiers jours sur mon 49" ont été un peu étrange.Mais on s'y adapte très très vite. Et en fait je pense que j'aurai du mal à revenir à un dual-screen classique. Bon faut un OS qui supporte bien l'ultrawide de base (genre Windows avec FancyZone et pas cette natasserie de MacOS), mais une fois les zones définies c'est du bonheur.En fait je regrette même que le Neo Geo ait pas 10cm de plus en hauteur, là ça serait parfait.

Depuis le passage au M1 avec virtiofs j'ai plus de problème de perfs.

Depuis quelques mois j'utilise Colima, les perfs sont ok, la stabilité un peu moins.

bah j'ai essayé, j'en suis revenu. Trop lourdingue.  
WSL2 et basta, la conf docker je me la tape que pour le déploiement.

 
Je ne sais pas si ça peut aider, mais tu pourrais tester https://github.com/runfinch/finch c'est construit autour de https://github.com/containerd/nerdctl qui a priori supporte docker-compose, donc en théorie c'est un remplacement "drop in" de la CLI "officielle" si j'ai bien compris le bouzin.

 
En quoi c'est plus lourdingue que d'utiliser WSL2 ?

 
c'est archi lent.

(puis je modifie un fichier en php je veux pas rebuild une machine complète pour voir le résultat, merci bien. )

Ces utilisateurs de PHP habitués au fast refresh, fast life, pourquoi tout le reste est compliqué.

stadire que ouais, passer de "je déploie mes sources sur une VM en 2 minutes" à "je tagge ma version pour relancer un build de l'image, qui va ensuite être déployée pour que dans un quart d'heure je puisse avoir le résultat", on a du mal à bien voir le progrès, depuis mon fauteuil

"C'est reproductible !"
"Adieu le it works on my machine"

 
Ouais, comme ça c'est le passage de la machine de dev à l'infra de test, le problème.

 
Euh... Je ne sais pas quel est ton workflow mais il m'a l'air bien lourdingue si tu dois rebuilder ton image à chaque modification de fichier

J'ai même déjà eu le cas où le même dockerfile donnait un résultat fonctionnel sur ma machine et non fonctionnel sur l'infra, à cause de la version d'une obscure lib sur l'hôte sur lequel ça déployait.
 
Vive le progrès.

Pet VS cattle.

L'intérêt est que ça soit toujours immutable.

Mais bon si ça met 15min à rebuilder et redéployer, le processus est peut être à améliorer.
Après forcément y a toujours un tradeoff.

et encore, tu pourrais passer à un truc genre "je modifie la config externalisée de mon back-end Spring Boot, et je dois faire une modif bidon dans ce back-end pour trigger son rebuild par Gitlab, lequel rebuild va trigger la régénération du pod correspondant par Kubernetes alors que l'intérêt d'une config externalisée est justement de ne pas recompiler derrière pour qu'elle soit prise en compte"

 
Le process j'ai pas la main dessus et je veux surtout pas avoir à y mettre le nez.
 
bref, dans mon coté, dev local tout simple >>> ce merdier overbloaté pour nos besoins Mais je ne suis probablement pas dans un cas "générique", sinon je comprends pas comment les gens mettent ces technos à la con partout à toutes les sauces

tu n'as pas idée

 
bah si tu veux une image qui se comporte de manière garantie d'une certaine manière, je vois pas comment tu peux modifier du code et ne pas devoir la recréer

bon sinon, jamais tu te connectes sous RocketChat ?

Comparer à setup un env local qui change à chaque projet, à switcher entre ton setup si tu bosses sur plusieurs projets à la fois, à avoir un env local iso avec ton env cible, j'opte pour les conteneurs sans hésitations.

WSL2 je veux bien, mais sous MacOSX ça va être compliqué
J'utilise WSL2 sous Windows, j'ai effectivement pas de soucis particulier.
 

Vu d'où je pars je veux bien tout essayer mais la contrainte plancher c'est qu'il y aura forcément une couche d'émulation je pense?
 

En même temps t'as une machine virtuelle entre les deux
 

You are doing it wrong.

 
jusqu'à ce que tu te mettes à dev des traitements qui durent plusieurs dizaines de minutes en local et où la version sous docker mets plusieurs heures à la place tellement c'est méga lent...

 
Probablement, mais concrètement avec les outils qu'on me file ici, quand je veux voir le résultat d'un changement sur notre infra de dev c'est ce qu'il se passe

Si l’image change pas à chaque édition c’est que ton image représente pas l’application mais juste son setup.
 
C’est une utilisation qui se défend, mais clairement c’est pas ce qui se fait chez monsieur skeye. Et sur un projet long terme, faut que le setup soit ultra touchy sa race pour que le fait de payer 15Go de disque pour que docker exécute un .sh vaille le coup. S’il a un setup local qui marche, pourquoi se faire chier à rajouter des middlemen?

Si tu changes des trucs c’est par définition pas immutable.

Pas un problème si t’es sur un nombre limité de projets qui durent longtemps/

Il est vrai que “cd” c’est compliqué.
 
Surtout que sans images tu peux partager des trucs, donc t’es pas nécessairement obligé d’avoir des tonnes de bordel redondants parce que des layers ont pas exactement le même setup donc tout est dupliqué

L’env cible il a 25 serveurs et quelques To de données, jamais mon env local y ressemble

Ici (et en règle générale là où je suis passé) : docker compose pour les 3rd parties : database, cache,... La stack se partage facilement et tu reproduis sans souci les configs de prod (clustering par ex).

Le back et le front dehors, y a pas vraiment d'intérêt à les mettre dans un container je trouve.

 
Oui, ça utilise Lima pour la VM.
 

 
Il me semblait que skeye parlait d'un env de dev.  
 

 
Si quand tu bosses sur plusieurs projets t'as juste les sources qui changent, tant mieux pour toi, mais ce n'est pas le cas de tout le monde.
 

 
Je ne parlais pas de l'infra mais de la partie soft, fait pas comme si tu n'avais pas compris

Si ton env de dev est différent de l'env de déploiement, du coup c'est quoi le bénéfice à pas juste faire ce qui t'arrange?

WSL te permet d'avoir autant de distribs que tu veux

 
Nan mais t'es pas obligé de build l'image à chaque fois que tu fais une modification de code pour que tu es le même env
 
T'auras toujours le même environnement sauf que le tiens en local n'est pas immutable.

Faut utiliser spring cloud configuration et avoir un endpoint sur ton pod pour refresh !