Christophe a écrit 473 commentaires

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.

Pour être précis, c'est une feature qui a sauté entre Kde 4 et 5.

Je n'en veux pas aux devs (même s'il faudrait qu'ils ferment ce bug "WONTFIX" pour être cohérents), je suis content avec Xfce.

Par contre, pour un besoin de niche, c'est tout de même le bug ouvert le plus commenté de tout Plasma Shell, et de loin… Mais cette métrique vaut ce qu'elle vaut, certes.

Et bien non, j'ai un grand écran, je ne mets aucune fenêtre en plein écran.

Surtout, je suis quand même assez bien placé pour déterminer ce qui me gêne ou non, je crois. Mais ce genre de réponse un tantinet surréaliste se retrouve régulièrement sur le long échange du rapport de bug de Kde correspondant.

Personnellement j'ai surtout deux arguments, qui sont peut-être devenus obsolètes:

1. peu de stabilité dans la configuration: au cours des mises à jour successives, ma configuration devenait de plus en plus bancale, et au bout de 2-3 ans je devais passer par un gros reset et tout refaire afin d'éviter des soucis bizarres.

2. pas de fond d'écran par bureau virtuel ! Cette demande, vieille de 7 ans, est toujours en standby chez KDE. C'est pour moi un repère visuel indispensable au quotidien. J'ai le même reproche pour Gnome, d'ailleurs.

Bref, Xfce est pour moi la bonne solution: stable, efficace, et j'ai mes fonds d'écran différents.

Réflexion intéressante; la dualité classement/tag n'est toujours pas résolue, malgré les années qui passent…

Pourtant les scénarios où les tags sont pertinents existent, là n'est pas le problème. Non, le problème c'est que les tags n'ont pas vraiment de standard: on peut étiqueter des fichiers sur Linux, sur certains clouds, mais il n'y a aucune synchronisation entre tout ça, contrairement aux structures de répertoires.

Et c'est même pire que ça: étiqueter un fichier dans Dolphin ne servira à rien lorsqu'on voudra retrouver ledit fichier avec le sélecteur de Gimp.

On le voit bien, il manque ici deux étapes majeures avant que les étiquettes soient vraiment un complément utile aux dossiers:
1. un standard pour stocker et retrouver l'information (niveau OS ?)
2. une synchronisation possible entre les différentes copies des fichiers (cloud, NAS, copies locales…) afin de retrouver la donnée sur différents types de support

Mais sans ça, les étiquettes restent pour moi un gadget inutilisable à grande échelle.

surtout que moderna provoque 6 fois plus de miocardite et péricardite que pfizer et là on parle de 100x plus de risque sans vaccin donc logiquement on pourrait remettre morderna

Oui… si on n'avait que Moderna sous la main. Mais en fait c'est comme avec A-Z: puisqu'il est facile d'avoir mieux, autant le proposer.