Christophe a écrit 465 commentaires

Parce que cela est déjà encadré par la loi, donc ça ne servirait pas à grand chose.

La police n'arrive manifestement pas à faire respecter cette loi sans utiliser une répression démesurée, on en arrive donc à se demander si elle fait plus de bien que de mal ici.

En considérant la thématique de LinuxFr, cliquer sur "inutile" a du sens. Et puis il y a peut-être un effet d'accumulation de tous ces liens postés par Madeiros, qui n'ont quasiment jamais de rapport avec avec Linux ou le libre.

Même si cela est bénéfique de s'ouvrir à d'autres idées, on est quand même sur LinuxFr, pas AntiNucFr ou ClimatFr…

C'est un piège !

Si c'est juste pour tester, peut-être tenter la voie de la VM ? Il y a sûrement des images toutes prêtes quelque part…

Je trouve que quand la source est une IA, c'est tout de suite plus pernicieux: le texte est crédible mais souvent inexact ou juste faux.

Et on n'est pas sur StackOverflow où d'autres vont pointer du doigt l'erreur subtile mais essentielle qui s'est glissée dans le texte: là, tu es seul face à un texte quasi unique.

L'humain à l'origine de l'erreur sur internet voulait sûrement donner une réponse juste ; ChatGPT produit seulement une réponse crédible. Une source comme ça est à fuir comme la peste.

Bilan rapide:
- Globalement, je n'ai pas eu à me plaindre de lenteurs ou de coupures: upload/download à 30-40Mo/s avec la fibre, en moyenne.
- Le client desktop Linux, c'est bien, mais il est un peu lourd… C'est du Electron, bof bof. Mais par contre, il fait le job
- pCloud propose un "coffre fort" en payant un peu plus, mais franchement avec rclone et son chiffrement côté client je n'en vois pas l'intérêt.
- de même, pCloud propose des "connecteurs" pour faire le backup de son compte Dropbox, Google, Facebook. Je ne l'utilise pas.
- pas de spam en email, je n'ai quasiment jamais rien reçu d'eux sauf pour des notifications de sécurité.
- possibilité sympa de faire un "unzip" côté serveur, m'a fait gagner pas mal de temps sur une archive avec plein de fichiers

Au final je suis un client satisfait, donc je vais continuer avec eux. J'utilise environ 650Go pour l'instant.

J'ai souscrit à pCloud (2To) il y a environ 2 ans; les commentaires précédents sont tout à fait pertinents, pas grand chose à redire.

Personnellement j'utilise rclone pour faire les sauvegardes, et ça juste marche.

J'ai payé le forfait il y a 2 ans, avec le raisonnement suivant: à partir de 3 ans d'utilisation, ce sera de toute façon moins cher qu'un abonnement, que je reste ou non.

Et même si pCloud n'est pas parfait, c'est une solution tout à fait acceptable pour moi (client de synchro linux, support rclone, bon débit, stockage en Europe, relativement indépendant des GAFAM, entreprise qui semble stable).

A voir avec tes critères, donc.

Oui, systemd débarque avec énormément de petits outils qui remplacent d'autres outils plus traditionnels (hostname, cron, automount, syslog, etc etc).

Mon opinion à moi (que je partage) est que cet aspect monolithique vient principalement d'un problème de packaging: systemd c'est tout ou rien, il est rarement possible de faire ses emplettes dans les fonctionnalités offertes par systemd.
Je pense que ça explique cette perception de pseudo-modularité de systemd […] essentiellement illusoire .
Ça décourage aussi les alternatives: systemd installe toujours ses implémentations d'interfaces sur le système, proposer une implémentation alternative est compliqué…

Passé ce cap, systemd fonctionne globalement très bien. Et en tant qu'utilisateur desktop, je suis content de pouvoir écrire facilement de petits services (automount, timers, services utilisateurs…) qui seront associés à ma session.

Oui, c'est le genre de petite interface qui pouvait répondre à ma question de ce journal …

Maintenant j'utilise un truc plus lourd ( filebrowser ) et j'en suis content, mais cette alternative peut être très utile aussi.

Il y a aussi pas mal de compositeurs (notamment les distribs pour smartphone) qui reposent sur QtWayland. Ce dernier rend l'écriture d'un compositeur très simple, on peut même faire ça en QML.

Le plus logique, c'est quand même d'archiver ce qui est dans un format standard, afin de ne pas s'enfermer dans un unique logiciel.

Je pense qu'il n'y a pas vraiment débat, Thunderbird devrait utiliser le format standard, point. Le reste n'est qu'un ensemble de bidouilles pour contourner ce manque…

Sans faire du C ? Vu le niveau de détail dans la gestion de la mémoire, ça pourrait tout aussi bien être du C…

Je ne suis pas sûr qu'on ait déduit la même chose de la lecture de cet article: pour moi, il montre surtout que le GC (et donc, la gestion mémoire) doit être finement pris en compte pour espérer rivaliser avec un langage sans GC.

Tout ça pour atterir à un code bien plus alambiqué et incompréhensible que son équivalent en C, d'ailleurs.

Non, c'est le dev qui est incompétent, nuance.

Non, c'est le GC (et/ou le compilateur) qui donnent un résultat moins efficace dans ce scénario. Et pour un langage de haut niveau comme C#, qui inclut un GC, je n'y vois rien de choquant. Le code de départ est maintenable; celui d'arrivée j'ai quelques doutes !

Très franchement, en lisant l'article, je ne sais pas vraiment quoi en déduire. En tout cas, je ne suis pas convaincu.

En effet, le code optimisé est très efficace, mais :

1. On passe d'un code lisible (je comprends bien ce qu'il fait, sans connaître C#) à un code dont la fonction de base est noyée dans les optimisations

2. Le résultat est rapide, principalement parce que… le GC n'a plus rien à faire. On précalcule, on réutilise des buffers, etc. Donc OK, le code est rapide, mais on peut très bien en conclure l'opposé de ce que tu sembles indiquer: dans ce langage avec GC, une façon d'obtenir de bons résultats est d'éviter ce boulet de GC.

On dirait: https://www.francetoner.fr/recherche/ref-TN-241BK?GENERIQUE (pour le noir)

C'est peut-être parce que ça se "conserve" bien, mais il semble qu'on trouve de vieux toners assez facilement.

Où est-il indiqué : "Attention, cet espace est public et peut être accédé par des tiers" ?

Ce n'est pas un tiers, c'est le fournisseur de stockage lui-même. Et même pour GMail, c'était marqué dès le début que les mails seront scannés de toutes parts…
Oui, Google scanne toutes tes interactions, il catégorise toutes tes photos (le tag automatique est très à la mode en ce moment). Quand on dit "le produit c'est toi", c'est bien ta vie privée qui est vendue.

à ce que la banque puisse ouvrir les coffres des clients pour voir s'ils ne font pas du blanchiment

Je ne serais pas étonné que ce soit le cas, il y a une coopération étroite entre le fisc et les banques.
Je t'invite à déposer régulièrement de grosses sommes en cash sur ton compte en banque, et à voir ce qu'il se passe…

Le fait que des gens ici défendent la possibilité que des données personnelles soient accessibles á tout va

Non, accessibles par celui qui héberge ces données. Une grosse pression a été mise sur les hébergeurs ces dernières années, et ils ont mit en place un protocole de vérification plus ou moins heureux.

Encore une fois, le cloud, ce n'est que l'ordinateur de quelqu'un d'autre. La dérive que tu pointes, c'est surtout qu'on a oublié ça…

Ensuite il est vrai que la loi ne sait pas trop quoi faire de ces espaces numériques, entre espace privé sanctifié et open-bar douteux.

Je crois que tu t'emballes un peu. La photo a manifestement été prise avec un appareil android, et téléchargée automagiquement sur Google Photos.

La suite (email, clinique, etc) n'a pas de lien technique avec ça.

Voire barbare

Apparemment Rust va utiliser l'approche "optional". Si le conteneur est vide, l'élément None est retourné.

entre ceux n'en voulant jamais de jamais et ceux faisant des benchs jusqu'à 10% des appels en exception

C'est effectivement binaire, mais je pense (en dehors du fait que je n'aime pas trop les exceptions) qu'il n'y a pas 42 façons d'utiliser les exceptions. En gros:

• pas du tout
• juste le strict minimum, en gros l'appli devient quasi inutilisable et on «plante élégamment»
• partout, comme système de gestion d'erreur par défaut

Faire un entre-deux est probablement le pire: on ne sait jamais si on doit gérer ou pas les exceptions, et du coup c'est géré de façon bancale.

Il y a sûrement des scénarios où une exception peut faire l'affaire. Mais personnellement, je trouve que le nombre de pièges que ça pose éclipse le gain en lisibilité.

En fait, ce sont essentiellement les mêmes pièges que goto: on perd la maîtrise du flux de la fonction.

Dans ton exemple, une exception est lancée 50 niveau en dessous. Il faut donc, systématiquement, et à chaque étage:

• s'assurer qu'il n'y a aucune fuite mémoire
• s'assurer qu'une transaction commencée sera annulée et/ou close

Tout ça, sachant que potentiellement sur 48 niveaux il n'y a aucun indice que l'appel de fonction lèvera une exception en plein milieu de l'algorithme…

Alors apparemment ça semble adapté à ton cas, tant mieux pour toi. Mais je reste attaché à ce que mes fonctions s'exécutent jusqu'à leur unique point de sortie, avec bien sûr une gestion des échecs d'appels aux sous-fonctions.

En effet, difficile de savoir ce qu'il en est réellement.

D'un côté, il y avait une MR récemment terminée, qui prévoyait exactement ce qui a fuité. De plus, vu l'avis de réunion dévoilé par TheRegister semblait indiquer que la décision était déjà plus ou moins actée.

D'un autre côté, ce n'est pas une communication officielle, et peut-être qu'une réunion en interne aurait changé la décision finale.

Ah, voilà, c'est bien mieux. Ils auraient pu commencer par ça, au lieu de faire peur à tout le monde…

Je me demande tout de même quel serait le gain s'ils passaient simplement à un archivage. Normalement cela divise le coût par 10 (ils utilisent le Google Cloud), ce n'est pas négligeable…

Je ne comprends pas comment cette décision pourrait être bénéfique à GitLab.

Le signal envoyé ici, c'est "n'utilisez plus gitlab.com pour stocker des projets potentiellement peu actifs". Donc, plus aucun projet perso, par exemple, et en fait, plus rien, car un an c'est très court.
De même, éviter de dépendre de projets stockés sur gitlab.com, et qui pourraient être trop peu actifs.

Pourtant il y a d'autres voies possibles:
- archiver ces projets (et non les supprimer)
- augmenter le prix de la solution commerciale
- diminuer l'espace offert gratuitement

Je parie qu'il y aura rétro-pédalage sous peu. Mais le mal est déjà fait… Microsoft se frotte les mains.

J'attends avec impatience le portage de Doom sur cette machine !