Disons que la VM a maintenant un deuxième disque sdb, avec une seule partition sdb1
Surtout pas malhereux …
Tu vas faire comment si tu dois étendre le disque ?
Pas besoin de partitionner le disque, il suffit juste de faire un pvcreate sur /dev/sdb. Le partitionnement sur le disque de boot n'a de raison d'être que pour démarrer la machine.
Je pensais, en effet, que la question du sens comme celle de la qualité du projet que défendent des entrepreneurs était la clé pour chacun d'entre vous. J'ai parfois l'impression d'en être bien loin.
Il faudrait qu'il retourne sur le terrain … La qualité pour beaucoup ça n'a pas de sens … Aujourd'hui on veut délivrer vite quitte à rogner sur la qualité, en ne raisonnant qu'à court terme et en faisant trimer justement ceux qui demandent des salaires mirobolants. Parce que justement le manque de qualité fait qu'on a besoin de personnes qui coutent cher pour rattraper les problèmes à la volée. Non seulement faut être doué mais faut aussi avoir du temps … et le temps c'est de l'argent (parce que faut pas rever … un bug de prod tous les jours qui fait que les personnes vont faire 50h par semaine au lieu de 35, les employeurs ne paieront pas … donc faut bien trouver son compte).
Ah puis ya aussi l'aspect éthique : pouvoir forcer qqn à bypasser ses principes pour livrer de la merde qui brulerea dans les semaines a venir … ça se paye. PErso faut me payer très cher pour me forcer à faire quelque chose en dehors de mes convictions.
A force de chercher l'offre mieux disante sans réfléchir à la réelle construction de carrière, sans faire le choix du manager qui va faire grandir et qui va inspirer, vous allez limiter les discussions avec vos futurs employeurs aux simples aspects transactionnels.
Ce mec n'a pas mis les pieds dans une entreprise depuis des années, surtout en société de services.
Les managers "qui vous font grandir" sont très rares. En général le manager va chercher à se faire grandir lui même bien souvent au détriment de son quipe, qui va devoir trimer pour que le manager puisse cacher a ses N+1, N+x son incompétence, et ça s'ajoute à chaque mlaillon de la chaine.
Sans parler des formations qui sont assez rares de nos jours …
Perso je connais pas mal de personnes qui demandent un salaire élevé, et qui sur ce salaire se payent les formations que leur employeur "censé les faire grandir" ne leur donne pas.
Pendant longtemps la plupart des distributions ont utilisé le sysvinit de Miquel van Smoorenburg sans que personne ne semble s’inquiéter d’un manque d’hétérogénéité.
Certes mais je pouvais facilement m'en passer et utiliser un autre système d'init …
Pendant longtemps la plupart des distributions ont utilisé le sys(k)logd de Greg Wettstein and Stephen Tweedie sans que personne ne semble s’inquiéter…
Oui mais je pouvais facilement utiliser une alternative.
Il y a sûrement des choses à critiquer dans systemd (citez-moi un programme qui ne soit pas critiquable), mais à mon avis pas celle-là.
Ca en plus du fait que systemd ne se contente pas d'être un système de démarrage ?
1.C'est pas genre un cheval mort le meme Systemd aujourd'hui ?
C'est à dire ?
Tu confondrais pas Systemd et le kernel ?
Non
Si tu considère que tout le monde a une version du kernel Linux différente (argument de hétérogénéité) pourquoi ça serait pas pareil pour Systemd, qui évolue très vite lui aussi ?
Bien sûr, mais c'est pas parce que le noyau est un potentiel vecteur d'attaque commun qu'on doit en poser d'autres …
4.Pourquoi te focaliser sur Systemd ? Il t'a fait mal quelque part ?
Honnêtement, sur ma machine je fais attention quand certaines librairies se mettent à jour
et j'ai toujours une appréhension quand je reboote suite à un changement noyau (même si je sais comment me sortir de ce genre de problème)
Pour moi c'est exactement ça … Je veux choisir de faire mes mises à jour au moment ou je peux potentiellement passer du temps à dépanner (et pas quand je dois imprimer en urgence un courrier important).
De ton côté tu vois les avantages d'un mode de fonctionnement, que je ne remets nullement en cause. Mais c'est juste avoir des oeilleres et refuser de voir que ce que tu fais ne peut pas forcément être fait ailleurs.
Sur d'anciens desktops ou laptops, le boot USB ne marche simplement pas (j'ai un vieux fujitsu comme ça). Sans ISO tu ne peux rien faire.
Ensuite, il est difficile chez certains hébergeurs de ne monter autre chose qu'une image iso popur un boot (ou rescue).
Perso, je préfère largement le stick usb, mais l'iso n'est certainement pas encore à jeter. Pourquoi ne pas laisser encore les deux cohabiter tranqulliement ?
Et c'est, évidemment, problématique et aberrant puisqu'on perd l'essentiel quand on veut commenter (encore des choix technique de mon point de vue peu réfléchis).
Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage)
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
La masse de bibliothèque c, java, python et js est absolument délirante
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
À l'époque où je m'étais amusé avec go faire de l'amqp ça ne se faisait pas trop avec la dernière version du langage.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).
Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
Attention, je crois que certains ont mal compris … je ne dis pas que c'est impossible, je n'ai juste aucune idée de comment on peut faire ça en dehors d'une machine virtuelle style JVM (et ça m'intéresse de savoir)
C clair mais perso ça ne m'empêche pas de penser la même chose (mais en un peu plus nuancé par contre. Le C ne disparaîtra pas du jour au lendemain, vu la quantité de code existant, mais pour moi c'est le seul langage suffisamment crédible pour prendre sa place au fil du temps).
Mais bon … Il me semble que derrière l'implémentation "officielle" Rust, c'est LLVM, et que LLVM supporte de plus en plus d'architectures et de processeurs. Puis si les compilos C/C++ proprios sont bien faits, les éditeurs ne devraient pas avoir trop de mal à les adapter quand le marché le demandera.
C'est sur qu'un utilisateur qui passe son temps à me répéter en boucle la même chose sans être plus précis dans ce qu'il veut, même lorsque je lui demande de décrire ce qu'il attend, en passant son temps à me dire "comme partout ailleurs", a la fin je l'envoie chier.
Pourtant dans ce genre de situation je suis assez patient … j'admets ne pas être en mesure de comprendre ce qu'on me dit, et quand je ne comprend pas je pose des questions … Et je m'attends à ce qu'on me précise son point de vue en reformulant. Dans beaucoup de cas les gens reprennent leur explication, précisent ce qu'ils veulent, font un schéma, etc …
Dans d'autre cas ya des gens comme toi qui passent leur temps a répéter la même phrase en boucle avec des marques de mépris du style "comme ça se fait partout ailleurs" (en sous entendu : pauvre con t pas capable d'aller voir ce qui se passe ailleurs pour comprendre ce que je dis), qui tentent de forcer leurs interlocuteurs à deviner (ce qui est fatiguant en soit), mais qui n'admettront jamais si la personne en face n'a pas compris que son explication n'était pas claire, pour ensuite lui dire de manière directe, ou par souis entendu que cette personne est incapable (tout en se faisant passer pour une victime).
Et malhereusement ces personnes sont aussi excécrable point de vue de caractère dans la vie … parce qu'elles n'hésitent pas à faire culpabiliser les autres par rapport à leurs faiblesses.
Du coup je crois que je vais arrêter là la discussion : ton disque rayé ça me gave. Si t pas fichue de passer un peu de temps à décrire claire ment ce que tu veux, c'est que tu ne le veut pas vraiment . Du coup arrête tes dénigrements du style "Je n’arrive même pas à comprendre comment on peut, a pu penser, concocter ça et trouver ce comportement satisfaisant. Ça me gêne énormément. Accessoirement (vraiment ?) : c’est un comportement très inhabituel, à peu près tous les sites et forums permettent de visualiser les contenus et, au moins, la page des commentaires sur laquelle on est. Donc, techniquement, c’est tout à fait possible…" ou autre arguments tels que j'ai vu passer sur un autre journal. Apres si quelqu'un a envie de dépenser tempsn, énergie et santé mentale avec tes demande, libre à lui … mais bon, je pense que c'est une perte de temps et d'énergie.
Non je l'expose très clairement, mais pas d'un point de vue technique.
Ben non. Tu n'es pas claire. En gros tu dis "je veux tout voir" … mais tu n'explique pas de manière concrête le quoi … Pour illustrer, tu nous dis en gros "je veux une maison" mais tu ne décris pas l'agencement des pièces que tu veux, en disant que tu veux comme partout ailleurs.
clic droit sur le lien=> ouvrir ds un nouvel onglet.
et encore moins pratique sur un terminal mobile.
On peut ouvrir des tabulations sur un smartphone, tout dépend peut etre du navigateur … Perso je le fais occasionnellement sur mon smartphone, mais c'est pas si rebutant que ça.
Mais bon … Ca veut pas dire qu'il ne faut pas améliorer, juste que je ne m"étais pas rendu compte du problème.
Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.
A côté les smart pointers de C++ et Rust sont intéressants, mais plus pénibles et ne gèrent pas tous les cas (à tel point que l'ajout d'un GC en Rust a été envisagé).
Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas … Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
Les deux sont des véhicules mais pas conçus pour les mêmes objectifs, et ne sont pas interchangeables. Du coup ça ne sert à rien de les comparer.
De mon avis une comparaison Go/Ada, comme celle qui est plus ou moins passée sur Lnuxfr ces derniers temps a déjà plus de sens, car les deux langages ont des approches parfois différentes pour répondre aux mêmes objectifs, mais ne pas oublier que même dans ce cas, la comparaison n'est pas non plus toujours pertinente, car les deux langages n'ont pas non plus les mêmes raisons d'etre.
Cela dit … j'aimerais bien que certains concepts Ada soient repris dans Rust. Ce que je trouve intéressant dans Ada par exemple, c'est que chaque type doit être redéfini et dérivé des types de bases avec contraintes (ça fait un bail que j'ai plus fait d'Ada donc je ne me rappelle plus des termes exacts, n'hésitez pas à corriger ou préciser).
[^] # Re: hou la ça remonte a loin ;)
Posté par totof2000 . En réponse au message Mais à qui appartient cette partition ?. Évalué à 1.
Surtout pas malhereux …
Tu vas faire comment si tu dois étendre le disque ?
Pas besoin de partitionner le disque, il suffit juste de faire un pvcreate sur /dev/sdb. Le partitionnement sur le disque de boot n'a de raison d'être que pour démarrer la machine.
[^] # Re: Une solution: le revenu universel unique
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 3.
Dans certains pays on éduque les enfants à planter des légumes, ou à fabriquer des vêtements, ou des jouets, ou des smartphones …
# La qualité ... Mort de rire ...
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 10.
Il faudrait qu'il retourne sur le terrain … La qualité pour beaucoup ça n'a pas de sens … Aujourd'hui on veut délivrer vite quitte à rogner sur la qualité, en ne raisonnant qu'à court terme et en faisant trimer justement ceux qui demandent des salaires mirobolants. Parce que justement le manque de qualité fait qu'on a besoin de personnes qui coutent cher pour rattraper les problèmes à la volée. Non seulement faut être doué mais faut aussi avoir du temps … et le temps c'est de l'argent (parce que faut pas rever … un bug de prod tous les jours qui fait que les personnes vont faire 50h par semaine au lieu de 35, les employeurs ne paieront pas … donc faut bien trouver son compte).
Ah puis ya aussi l'aspect éthique : pouvoir forcer qqn à bypasser ses principes pour livrer de la merde qui brulerea dans les semaines a venir … ça se paye. PErso faut me payer très cher pour me forcer à faire quelque chose en dehors de mes convictions.
[^] # Re: AH ah ah
Posté par totof2000 . En réponse au lien Chasseurs de têtes : arrêtez de demander plus que le SMIC. Évalué à 10.
Ce mec n'a pas mis les pieds dans une entreprise depuis des années, surtout en société de services.
Les managers "qui vous font grandir" sont très rares. En général le manager va chercher à se faire grandir lui même bien souvent au détriment de son quipe, qui va devoir trimer pour que le manager puisse cacher a ses N+1, N+x son incompétence, et ça s'ajoute à chaque mlaillon de la chaine.
Sans parler des formations qui sont assez rares de nos jours …
Perso je connais pas mal de personnes qui demandent un salaire élevé, et qui sur ce salaire se payent les formations que leur employeur "censé les faire grandir" ne leur donne pas.
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 3.
Par contre ici on arrive à faire courir les aficionados du canasson … :)
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
Certes mais je pouvais facilement m'en passer et utiliser un autre système d'init …
Oui mais je pouvais facilement utiliser une alternative.
Ca en plus du fait que systemd ne se contente pas d'être un système de démarrage ?
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 2.
C'est à dire ?
Non
Bien sûr, mais c'est pas parce que le noyau est un potentiel vecteur d'attaque commun qu'on doit en poser d'autres …
Oui.
[^] # Re: Linux n'est pas uniforme
Posté par totof2000 . En réponse au journal Coût de piratage des serveurs Linux. Évalué à 4.
Pour moi c'est exactement ça … Je veux choisir de faire mes mises à jour au moment ou je peux potentiellement passer du temps à dépanner (et pas quand je dois imprimer en urgence un courrier important).
[^] # Re: Entièrement d'accord
Posté par totof2000 . En réponse au lien L'heure de la retraite pour les images ISO des distributions ?. Évalué à 3.
De ton côté tu vois les avantages d'un mode de fonctionnement, que je ne remets nullement en cause. Mais c'est juste avoir des oeilleres et refuser de voir que ce que tu fais ne peut pas forcément être fait ailleurs.
Sur d'anciens desktops ou laptops, le boot USB ne marche simplement pas (j'ai un vieux fujitsu comme ça). Sans ISO tu ne peux rien faire.
Ensuite, il est difficile chez certains hébergeurs de ne monter autre chose qu'une image iso popur un boot (ou rescue).
Perso, je préfère largement le stick usb, mais l'iso n'est certainement pas encore à jeter. Pourquoi ne pas laisser encore les deux cohabiter tranqulliement ?
[^] # Re: Et pour les dépêches
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
Encore du dénigrement …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.
C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.
Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.
La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.
Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
De mon avis … Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'éléménts qui plaident en sa faveur, dont un particulier : le coté gestion safe de la mémoire contrôlé à la compilation, sans (trop) d'impact au runtime. Et ça c'est quelque chose qu'on ne trouve pas en C, et qui dans les systèmes modernes est de plus en plus problématique. De mon avis … il faudrait que le C évolue pour permettre nativement une gestion safe de la mémoire de la même façon pour ne pas être abandonné progressivement.
Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2.
Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.
Je trouve ça dommage car c'est un langage que je trouve intéressant. Cela dit aujourd'hui je ne suis pas sûr que ce soit une bonne idée de l'utiliser pour un nouveau projet.
[^] # Re: Le choix est simple
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 1.
Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).
[^] # Re: Le choix est simple
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 1.
Attention, je crois que certains ont mal compris … je ne dis pas que c'est impossible, je n'ai juste aucune idée de comment on peut faire ça en dehors d'une machine virtuelle style JVM (et ça m'intéresse de savoir)
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 1.
C clair mais perso ça ne m'empêche pas de penser la même chose (mais en un peu plus nuancé par contre. Le C ne disparaîtra pas du jour au lendemain, vu la quantité de code existant, mais pour moi c'est le seul langage suffisamment crédible pour prendre sa place au fil du temps).
Mais bon … Il me semble que derrière l'implémentation "officielle" Rust, c'est LLVM, et que LLVM supporte de plus en plus d'architectures et de processeurs. Puis si les compilos C/C++ proprios sont bien faits, les éditeurs ne devraient pas avoir trop de mal à les adapter quand le marché le demandera.
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2. Dernière modification le 09 décembre 2021 à 22:35.
Moi ça me fait penser également à la mort annoncée des mainframes depuis plus de 20 ans …
Pourtant ça vit encore, et même bien. On y fait même tourner du Linux et du kube via Openshift …
[^] # Re: Commenter directement dans le fil ?
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
C'est sur qu'un utilisateur qui passe son temps à me répéter en boucle la même chose sans être plus précis dans ce qu'il veut, même lorsque je lui demande de décrire ce qu'il attend, en passant son temps à me dire "comme partout ailleurs", a la fin je l'envoie chier.
Pourtant dans ce genre de situation je suis assez patient … j'admets ne pas être en mesure de comprendre ce qu'on me dit, et quand je ne comprend pas je pose des questions … Et je m'attends à ce qu'on me précise son point de vue en reformulant. Dans beaucoup de cas les gens reprennent leur explication, précisent ce qu'ils veulent, font un schéma, etc …
Dans d'autre cas ya des gens comme toi qui passent leur temps a répéter la même phrase en boucle avec des marques de mépris du style "comme ça se fait partout ailleurs" (en sous entendu : pauvre con t pas capable d'aller voir ce qui se passe ailleurs pour comprendre ce que je dis), qui tentent de forcer leurs interlocuteurs à deviner (ce qui est fatiguant en soit), mais qui n'admettront jamais si la personne en face n'a pas compris que son explication n'était pas claire, pour ensuite lui dire de manière directe, ou par souis entendu que cette personne est incapable (tout en se faisant passer pour une victime).
Et malhereusement ces personnes sont aussi excécrable point de vue de caractère dans la vie … parce qu'elles n'hésitent pas à faire culpabiliser les autres par rapport à leurs faiblesses.
Du coup je crois que je vais arrêter là la discussion : ton disque rayé ça me gave. Si t pas fichue de passer un peu de temps à décrire claire ment ce que tu veux, c'est que tu ne le veut pas vraiment . Du coup arrête tes dénigrements du style "Je n’arrive même pas à comprendre comment on peut, a pu penser, concocter ça et trouver ce comportement satisfaisant. Ça me gêne énormément. Accessoirement (vraiment ?) : c’est un comportement très inhabituel, à peu près tous les sites et forums permettent de visualiser les contenus et, au moins, la page des commentaires sur laquelle on est. Donc, techniquement, c’est tout à fait possible…" ou autre arguments tels que j'ai vu passer sur un autre journal. Apres si quelqu'un a envie de dépenser tempsn, énergie et santé mentale avec tes demande, libre à lui … mais bon, je pense que c'est une perte de temps et d'énergie.
[^] # Re: Commenter directement dans le fil ?
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
Ben non. Tu n'es pas claire. En gros tu dis "je veux tout voir" … mais tu n'explique pas de manière concrête le quoi … Pour illustrer, tu nous dis en gros "je veux une maison" mais tu ne décris pas l'agencement des pièces que tu veux, en disant que tu veux comme partout ailleurs.
[^] # Re: Commenter directement dans le fil ?
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
Le format dans lequel tu le veux (dans le sens : ce que tu veux voir affiché à l'écran).
[^] # Re: Commenter directement dans le fil ?
Posté par totof2000 . En réponse à l’entrée du suivi Pouvoir voir le contenu et le fil des commentaires quand on veut commenter. Évalué à 1 (+0/-0).
Oui mais a force on s'y fait …
clic droit sur le lien=> ouvrir ds un nouvel onglet.
On peut ouvrir des tabulations sur un smartphone, tout dépend peut etre du navigateur … Perso je le fais occasionnellement sur mon smartphone, mais c'est pas si rebutant que ça.
Mais bon … Ca veut pas dire qu'il ne faut pas améliorer, juste que je ne m"étais pas rendu compte du problème.
[^] # Re: Avec tar
Posté par totof2000 . En réponse au message rsync, plusieurs sources, plusieurs destination. Évalué à 2.
find avec l'option mtime peut t'aider … Sinon il y a aussi le couple dump/restore.
[^] # Re: Le choix est simple
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 0.
Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.
Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas … Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …
[^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 2. Dernière modification le 09 décembre 2021 à 09:31.
:) Je ne compare ni Rust ni Go à un 38 tonnes :) Autre illustration: c'est comme comparer A et B sous prétexte que ce sont deux lettres de l'alphabet.
Quel crétin je fais …. Ct pas Go/ada ton journal Rust/Ada :). Est-ce quer l'équipe de modération pourrait corriger SVP (avec le lien en prime ?).
Merci d'avance.
# Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.
Posté par totof2000 . En réponse au lien Rust versus Go : round 1, fight !. Évalué à 6.
Les deux sont des véhicules mais pas conçus pour les mêmes objectifs, et ne sont pas interchangeables. Du coup ça ne sert à rien de les comparer.
De mon avis une comparaison Go/Ada, comme celle qui est plus ou moins passée sur Lnuxfr ces derniers temps a déjà plus de sens, car les deux langages ont des approches parfois différentes pour répondre aux mêmes objectifs, mais ne pas oublier que même dans ce cas, la comparaison n'est pas non plus toujours pertinente, car les deux langages n'ont pas non plus les mêmes raisons d'etre.
Cela dit … j'aimerais bien que certains concepts Ada soient repris dans Rust. Ce que je trouve intéressant dans Ada par exemple, c'est que chaque type doit être redéfini et dérivé des types de bases avec contraintes (ça fait un bail que j'ai plus fait d'Ada donc je ne me rappelle plus des termes exacts, n'hésitez pas à corriger ou préciser).