Un régime parlementaire où ils arrivent pas à faire une alliance qui tient suffisamment pour avoir une audience royale.

Disons que YouTube a du pas mal saccager leur audience, quand tu vois un GeraldUndone, McKinnon ou même Polin (ce type m'insupporte) faire une review assez complète, sans compter les 300 videos de pleins d'autres gens qui couvrent tous les aspects imaginables, ça doit etre dur de rester compétitif.
Ils sont passés au format vidéo aussi, mais trop peu à mon sens.

nan mais stop : bien sur que je peux ne pas cliquer sur la popup MacOS, mais elle va revenir, ça règle pas exactement le problème, et je dois le gérer. Sur les autres OS j'ai pas besoin, un reboot fait la MAJ.
Sur tous les OS je peux ne pas faire la MAJ, mais ça m'intéresse vaguement de faire les MAJ, simplement je veux pas perdre 20 minutes à chaque fois. Et là MacOS est une merde infâme à ce niveau. Sur n'importe quel autre OS, si je dédcide de faire la MAJ, je peux continuer à bosser peinard, sachant que ça n'impactera que mon prochain reboot, et pas beaucoup.
Sous MacOS j'ai le choix entre :  
- pas faire la MAJ
- accepter la MAJ, et là quand le telechargement est fini le PC rebootera, et je vais perdre 20min avec la pomme blanche.

je suis désolé mais aucun de ces choix ne sont valables en 2023. MacOS a été un très bon OS au début des années 2000, c'est juste dommage que ce soit resté bloqué à cette époque

 
mauvaise foi de l'espace Monsieur Dion
 
Windows :  
- l'update se fait 100% silencieusement (rien à accepter, le download est silent)
- au reboot (si tu décides de le faire, t'es pas obligé si t'as pas le temps) t'as un petit message pour choisir update and reboot ou update and shut down
- quand ça reboote, 9 fois sur 10 c'est juste un reboot normal, t'as la main sur ton PC moins d'une minute après, sauf grosse MAJ ou c'est 1-2 minutes après
 
Sous Mac :  
- faut "accepter" l'update, ce qui en fait déclenche juste le téléchargement
- ça reboote sans trop te demander ton avis une fois le telechargement fini
- tu te tapes la pomme blanche avec la petite barre de progression et ça peut durer 20minutes avant de reprendre la main
 
Sous linux :  
- META + Enter (ça ouvre un terminal), "paru", je dois taper mon mot de passe et faire 2x "Y". Et voilà, mon système est presque à jour, il le sera complètement après un reboot normal
 
Sous ChromeOS :  
- des fois t'as environ 3' de délai quand le PC boote, parce qu'il vient de se mettre à jour
 
Ces expériences sont toutes parfaitement équivalentes, en effet surtout si on considère l'aspect : délai entre la MAJ et le moment où tu récupères la main

Donc maintenant "rebooter quand ça veut" cela veut dire "je fais l'action manuelle de cliquer sur un bouton pour rebooter immédiatement", propre.

Donc maintenant "rebooter quand ça veut" cela veut dire "je fais l'action manuelle de cliquer sur un bouton pour rebooter immédiatement", propre.
Le prix à payer pour cropper des images en toute tranquillité    
 
 
Vous n'arrivez même pas à faire un compteur de playlist, le truc le plus basique du monde, alors je ne sais pas si tu es super bien placé

 
Quand votre voisin de gauche rachète la banque à la moitié de sa valeur, il doit bien donner 17% des artichauts qu'il a gagné pendant la dernière donne ? Non parce que si vous faites artichette, et que vous collez le banquier à -6, vous pouvez tenter la raitournelle, et balancer les annonces. Donc on est d'accord, artichette, tichette de 2, tichette de 3, tichette de 21, michette, chiédèque, mique , sganabadarlane, résiné et raitournelle

On va partir sur un workflow git trunk base development.
 
En cas de hotfix, notre lead QA veut tirer la branche à partir du head de main et non pas du dernier tag (celui en prod donc).
 
Je trouve que c'est une mauvaise idée mais je suis à cours d'argument. Pour lui deployer tout ce qu'il y a sur main depuis la dernière mep juste pour un hotfix n'est pas un soucis car main devrait toujours être stable et les features devrait être gérée par des features flags donc il ne voit pas le problème.

On va partir sur un workflow git trunk base development.
 
En cas de hotfix, notre lead QA veut tirer la branche à partir du head de main et non pas du dernier tag (celui en prod donc).
 
Je trouve que c'est une mauvaise idée mais je suis à cours d'argument. Pour lui deployer tout ce qu'il y a sur main depuis la dernière mep juste pour un hotfix n'est pas un soucis car main devrait toujours être stable et les features devrait être gérée par des features flags donc il ne voit pas le problème.

 
Quand tu veux corriger un bug de prod, tu veux travailler sur la même codebase que la prod et avoir le même comportement que la prod.
On se fout que main soit stable ou pas stable c'est pas le sujet, si main est différent de la prod, ce n'est pas un point de départ approprié pour comprendre le problème de prod et le corriger efficacement.
 
En gros il rend plus difficile le travail des gens qui vont faire les hotfixes, sans aucun avantage particulier.

 
J'ai déjà tenté cet argument aussi

D'abords je clique, ensuite la mise à jour se télécharge, ensuite entre 10 et 2500 minutes plus tard, le bouzin se met à tout fermer et redémarre.

1/ non mais t'as décidé d'etre de mauvaise foi. Un update c'est a/ télécharger l'update b/ l'appliquer. Sous Mac quand tu cliques ça déclenche a/ (parce que ce serait dommage de télécharger en background), et donc quand tu déclenches a/, tu ne sais pas quand b/ va arriver exactement vu qu'ils s'enchainent. Sur les autres OS a/ se fait en background, et donc tu as le choix précis de quand déclencher b/. Je veux dire je peux littéralement te citer TOUS les autres OS desktops, ils font tous mieux. MacOS est en maintenance mode, c'est triste mais c'est une réalité. En attendant Windows a eu des bonnes avancées sur ce point avec win10 et win11, et Linux et ChromeOS étaient super propres dès le début.

2/ c'est en effet totalement comparable

Cette quote est anachronique. Les nombres négatifs sont apparus en occident au mieux qu'au 15e siècle, et c'est marrant comme ce concept qui nous semble évident a mis du temps à s'imposer même chez les scientifiques.
 
 Lazare Carnot (1753 ; 1823) :
« Pour obtenir réellement une quantité négative isolée, il faudrait retrancher une quantité effective de zéro, ôter quelque chose de rien : opération impossible. Comment donc concevoir une quantité négative isolée ? »
 
« L’usage des nombres négatifs conduit à des conclusions erronées. »
 
Maclaurin (1742):
« L’usage du signe négatif en algèbre donne lieu à plusieurs conséquences qu’on a d’abord peine à admettre et ont donné l’occasion à des idées qui paraissent n’avoir aucun fondement réel. »

 
J'ai déjà tenté cet argument aussi

 
Ah putain c'est chaud quand même. Mais par contre le lead QA devrait pas être décisionnaire sur un truc pareil ?

Cette quote est anachronique. Les nombres négatifs sont apparus en occident au mieux qu'au 15e siècle, et c'est marrant comme ce concept qui nous semble évident a mis du temps à s'imposer même chez les scientifiques.
 
 Lazare Carnot (1753 ; 1823) :
« Pour obtenir réellement une quantité négative isolée, il faudrait retrancher une quantité effective de zéro, ôter quelque chose de rien : opération impossible. Comment donc concevoir une quantité négative isolée ? »
 
« L’usage des nombres négatifs conduit à des conclusions erronées. »
 
Maclaurin (1742):
« L’usage du signe négatif en algèbre donne lieu à plusieurs conséquences qu’on a d’abord peine à admettre et ont donné l’occasion à des idées qui paraissent n’avoir aucun fondement réel. »

On va partir sur un workflow git trunk base development.
 
En cas de hotfix, notre lead QA veut tirer la branche à partir du head de main et non pas du dernier tag (celui en prod donc).
 
Je trouve que c'est une mauvaise idée mais je suis à cours d'argument. Pour lui deployer tout ce qu'il y a sur main depuis la dernière mep juste pour un hotfix n'est pas un soucis car main devrait toujours être stable et les features devrait être gérée par des features flags donc il ne voit pas le problème.

C'est complètement con.

On va partir sur un workflow git trunk base development.
 
En cas de hotfix, notre lead QA veut tirer la branche à partir du head de main et non pas du dernier tag (celui en prod donc).
 
Je trouve que c'est une mauvaise idée mais je suis à cours d'argument. Pour lui deployer tout ce qu'il y a sur main depuis la dernière mep juste pour un hotfix n'est pas un soucis car main devrait toujours être stable et les features devrait être gérée par des features flags donc il ne voit pas le problème.

 
C'est une belle théorie, dans un monde idéal rempli de poneys arc-en-ciel c'est en effet la chose à faire.

Moi je clique et ça télécharge, puis après cela me demande si je veux redémarrer maintenant ou plus tard ("dans une heure" ou "ce soir" je crois), jamais l'OS ne m'a fermé mes programmes sans me demander mon avis.

Même si main === dernier tag, il faut quand même lui expliquer pour des raisons de branching. Quoi que un tag n'est pas une branche, il faudrait dans ce cas avoir une branche de ce qui est actuellement en prod.
 
Edit GPT-4 :  
 
Il est vrai que, dans un monde idéal, la branche principale (main) devrait toujours être stable et les nouvelles fonctionnalités devraient être gérées par des feature flags. Cependant, il y a plusieurs raisons pour lesquelles créer une branche de hotfix à partir du dernier tag en production est une meilleure pratique.
 
Contrôle des modifications déployées : En créant une branche de hotfix à partir du dernier tag en production, vous vous assurez que seules les modifications nécessaires pour résoudre le problème urgent sont déployées. En utilisant le head de main, vous pouvez potentiellement déployer d'autres modifications non testées ou non validées qui pourraient causer d'autres problèmes.
 
Stabilité de la production : Même si main devrait être stable, il y a toujours un risque que des bogues ou des problèmes de compatibilité se soient glissés dans les commits récents. En partant du dernier tag en production, vous minimisez ces risques et garantissez que la version de production reste aussi stable que possible.
 
Séparation des préoccupations : Les hotfixes sont par nature des correctifs pour des problèmes critiques en production. En partant du dernier tag en production, vous assurez une séparation claire entre les correctifs d'urgence et les développements en cours sur main.
 
Historique clair : Créer des branches de hotfix à partir du dernier tag en production facilite le suivi des modifications déployées en production. Cela permet également de simplifier la gestion des versions et de faciliter la communication entre les équipes.
 
Tests et validation : Il est possible que les nouvelles fonctionnalités ou modifications sur main n'aient pas encore été testées ou validées par l'équipe QA ou les parties prenantes. En déployant ces modifications en production sans validation appropriée, vous augmentez les risques pour la stabilité de l'environnement de production.
 
En conclusion, même si votre lead QA pense que main devrait toujours être stable et que les fonctionnalités devraient être gérées par des feature flags, il est important de considérer les risques potentiels pour la stabilité de la production en déployant des modifications non testées ou non validées. Créer des branches de hotfix à partir du dernier tag en production est une meilleure pratique pour minimiser ces risques et garantir un historique clair des modifications déployées.

Cette quote est anachronique. Les nombres négatifs sont apparus en occident au mieux qu'au 15e siècle, et c'est marrant comme ce concept qui nous semble évident a mis du temps à s'imposer même chez les scientifiques.
 
 Lazare Carnot (1753 ; 1823) :
« Pour obtenir réellement une quantité négative isolée, il faudrait retrancher une quantité effective de zéro, ôter quelque chose de rien : opération impossible. Comment donc concevoir une quantité négative isolée ? »
 
« L’usage des nombres négatifs conduit à des conclusions erronées. »
 
Maclaurin (1742):
« L’usage du signe négatif en algèbre donne lieu à plusieurs conséquences qu’on a d’abord peine à admettre et ont donné l’occasion à des idées qui paraissent n’avoir aucun fondement réel. »

Moi je clique et ça télécharge, puis après cela me demande si je veux redémarrer maintenant ou plus tard ("dans une heure" ou "ce soir" je crois), jamais l'OS ne m'a fermé mes programmes sans me demander mon avis.
 
 
La mauvaise foi elle a peut être commencé à ton premier pâté où tu déblatérais des trucs faux, alors que le sujet était autre. Je n'ai pas dis que c'était mieux sur macos, j'ai dis que t'étais passé à windows 11 et que tu étais potentiellement impacté par Acropalypse    

 
Là aussi j'en suis convaincu mais j'ai pas de meilleurs argument.
 
Du coup je vais appliquer la théorie du nez dans le caca

 
KOSKOZ  
KOSKOZ

Tiens question conne, comme j'ai vu les réponses que me donne GPT-4, vous vous êtes abonnés à chat-gpt plus ?  
je regrette pas, ça rend service et me fais gagner du temps pour des conneries.

 
Là aussi j'en suis convaincu mais j'ai pas de meilleurs argument.
 
Du coup je vais appliquer la théorie du nez dans le caca

Arrêtez votre char, ça changera probablement rien. Bien sûr c'est mieux, ça montre une incompréhension profonde du concept de hotfix et de l'utilité de git. Le monsieur a peur de faire un truc qu'il comprend pas. Franchement ça arrive, c'est dommage qu'il fasse pas confiance aux experts, mais ce serait moi je dirais clairement pourquoi je suis pas d'accord, et je ferais comme il veut.

 
Food $200
Data $150
Rent $800
AI subscriptions $3,600
Utility $150
someone who is good at the economy please help me budget this. my family is dying

On va partir sur un workflow git trunk base development.
 
En cas de hotfix, notre lead QA veut tirer la branche à partir du head de main et non pas du dernier tag (celui en prod donc).
 
Je trouve que c'est une mauvaise idée mais je suis à cours d'argument. Pour lui deployer tout ce qu'il y a sur main depuis la dernière mep juste pour un hotfix n'est pas un soucis car main devrait toujours être stable et les features devrait être gérée par des features flags donc il ne voit pas le problème.

Quand tu veux corriger un bug de prod, tu veux travailler sur la même codebase que la prod et avoir le même comportement que la prod.
On se fout que main soit stable ou pas stable c'est pas le sujet, si main est différent de la prod, ce n'est pas un point de départ approprié pour comprendre le problème de prod et le corriger efficacement.
 
En gros il rend plus difficile le travail des gens qui vont faire les hotfixes, sans aucun avantage particulier.

 
Food $200
Data $150
Rent $800
AI subscriptions $3,600
Utility $150
someone who is good at the economy please help me budget this. my family is dying

 
Food $200
Data $150
Rent $800
AI subscriptions $30
Utility $150
someone who is good at the economy please help me budget this. my family is dying

Tu es encore sur une bien belle mission en tout cas, pourquoi tu vas pas chez plam comme tout le reste du topic ?

Y’a quand même une info majeure qui manque: quelle est la fréquence de déploiement? Parce-que si c’est déployé tous les lundis, avoir un déploiement hotfix déployé de la même branche le mardi ou le jeudi c’est probablement pas un gros problème, sauf si toute la QA du batch est faite le vendredi.

Par contre effectivement si c’est déployé tous les 3 mois, et que la QA se fait pas nécessairement en continu ou que tu peux avoir pas mal de features qui ont pas été QA et que les flux métier sont régulièrement pêtés en trunk alors c’est clairement con, tu augmentes vachement le risque pour rien, et tu vas te retrouver avec du hotfix en cascade parce qu’il faudra hotfix le hotfix pour les problèmes de QA.

Et techniquement c'est remboursé rapidement

 
T'as GitHub Copilot aussi et imho Chat GPT c'est clairement pas remboursé rapidement surtout quand je vois l'absolue nullité du truc généré plus haut dont t'avais l'air vachement content.

T'as GitHub Copilot aussi et imho Chat GPT c'est clairement pas remboursé rapidement surtout quand je vois l'absolue nullité du truc généré plus haut dont t'avais l'air vachement content.

T'inquiète pas les 20 balles me servent pour pleins de choses et le temps gagné, je l'utilise pour du free derrière. Donc ouais c'est pour moi remboursé. Il me faut une heure dans le mois pour rembourser mes 2 abonnements

 
Food $200
Data $150
Rent $800
AI subscriptions $3,600
Utility $150
someone who is good at the economy please help me budget this. my family is dying