Christophe a écrit 478 commentaires

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 !

Il faudrait changer le petit drapeau, ce n'est pas du Français… (Esperanto ?)

Oui mais non… C'est un login/pass pour se connecter à un serveur (mail) tiers, pas au serveur "de" K9Mail, qui n'existe pas.

C'était une semaine particulièrement longue.

Bien vu, j'avais raté celui-là ! En effet, ça marche bien, donc c'est une solution possible à mon problème :-)

Je vais continuer sur UpDog pour l'instant, mais je garde ça sous le coude, merci !

C'est vrai que c'est séduisant. Je vais voir avec UpDog pour l'instant, mais NC reste bien sûr une possibilité.

Merci pour ce retour !

"Mouif". C'est ce qui s'est passé pour Noël: on m'a envoyé des photos par email. Alors oui, en gros ça marche, mais je trouve ça un peu décevant quand même.

Et puis, en plus d'être une étape très manuelle (récupérer les pièces jointes, faire le transfert soi-même), on se heurte aux limitations de ce mode d'envoi: taille de la pièce jointe, dégradation de l'image (pour Whatsapp)…

Pour répondre sur Piwigo: c'est effectivement ce que j'ai utilisé au tout début pour mon RaspberryPi 4. Il y a plein de plugins, ça gère les sous-albums, c'est souple et il y a une app sur Android.

Mais… ce n'est pas adapté à une gestion de gallerie calquée sur le système de fichiers. Et typiquement c'est un problème pour le transfert de photos: ça va aterrir dans un dossier interne à Piwigo, complètement séparé de la gallerie principale.
Pour tous ceux qui ont demandé une solution sur les forums, la proposition est toujours la même: transférer via FTP ou autre, puis re-synchroniser la base de données. Autrement dit: ça ne répond pas à mon problème de tranfert de photos.

KDEconnect ne marche que sur un LAN, ce qui ne conviendra pas ici.

J'avais essayé un peu syncthings, mais j'ai trouvé le pairage et l'utilisation assez complexe, comparé à ce que je voudrais faire.

Mais en fait, après avoir discuté avec les méta-experts de la tribune, j'ai peut-être trouvé mon bonheur dans un des gestionnaires de fichiers "web", du type filestash.app. Ce dernier me semble un peu compliqué à installer sur un RaspberryPi, mais j'ai trouvé plus basique et plus simple, avec UpDog .

UpDog semble répondre à mes critères:

• simple à installer: pas d'installation ! (juste une URL à donner à mes contacts, et pourquoi pas une URL par contact d'ailleurs)
• raisonnablement sécurisé (mot de passe Basic Auth)
• simple à utiliser: éventuellement créer un sous-dossier, puis cliquer sur le gros bouton "Choose a File" puis "Upload"

Il me restera ensuite à mettre ces fichiers dans ma gallerie, mais au moins le transfert est simple et ne demande pas d'app à installer. Ça me semble être la bonne voie pour mon cas.

Alors qu'aujoud'hui, notre parcours santé est stocké sur une base centralisée, sensible, à laquelle tous les professionnels de santé peuvent accéder.
La différence ? Ah oui, moi, je n'ai accès à rien.

Sans remettre en cause les questions légitimes sur la sécurité de ce système, je vois surtout l'Espace Santé comme une petite ouverture du système existant au patient.

En effet, le cas d'une compilation d'un cross-compilateur est un peu spécial, et demande des termes plus précis.

Par contre, ce n'est pas le cas d'usage de TuxMake, qui se destine à compiler un noyau pour une cible donnée. Dans ce cas, réutiliser le vocabulaire de Yocto a plus de sens que d'utiliser celui de GNU, que je trouve un peu moins intuitif.

Déjà, la bonne réponse dépend du serveur graphique: X11 ? Wayland ?

Pour ce premier, bien vérifier que la variable DISPLAY existe dans le terminal. Sa valeur devrait probablement être "DISPLAY=:0".
Si la variable n'est pas là c'est quand même surprenant.

Si c'est Wayland, alors apparemment Qt a choisi la mauvaise plateforme, ce qui serait surprenant. Essayer "-platform wayland" en argument.

s/vanité/gêne/

Fixed.