Christophe a écrit 592 commentaires

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.

Il faut quand même avoir de sacrées oeillères pour ne pas voir l'amélioration qu'a apporté le vaccin. Par où commencer ?

• regarder les vagues pré-vaccin (avant l'été, par exemple Avril) et post-vaccin (après l'été, par exemple Août-Septembre): alors qu'on n'a même pas atteint une couverture vaccinale optimale, les hospitalisations sont déjà divisées par 2 ou 3
• on oublie un peu l'ampleur de la vague actuelle: on 10 voire 20 fois plus de cas quotidiens que pour les vagues précédentes ! Omicron est heureusement un peu moins virulent, mais sans le vaccin on serait en confinement depuis longtemps.
• on peut envisager un avenir moins morose: le Danemark tente le retour à une vie normale par exemple, chose absolument impensable sans le vaccin. Et oui, la 3ème dose y joue un rôle important, car elle une bien meilleure protection face à Omicron.

Alors, non, personne n'a «remarqué» que la vaccination n'avait eu aucun effet sur l'épidémie dans les derniers mois, c'est juste une impression très biaisée.

Pas de haine, mais juste une très grande lassitude.

Sur la plupart des projets auxquels je contribue, il arrive assez régulièrement qu’un patch soit initialement ignoré, jusqu’à ce que son auteur envoie un second mail après une semaine ou deux pour dire un truc du genre « ping ! juste pour savoir si vous avez bien vu ce patch et le cas échéant ce que vous en pensez ? »

Et après ces nombreuses contributions passées à la trappe par erreur, personne ne se dit que le process doit être amélioré ?

C’est plus une question de disponibilités des mainteneurs qu’une question d’outil, à mon avis.

Je ne suis pas de cet avis. Tu as deux problèmes distincts:

• la quantité de problèmes qu'une équipe réduite pourra régler (besoin d'une relance pour pousser la priorité)
• une visibilité de l'ensemble des problèmes (risque d'un oubli complet, besoin d'une relance pour simplement ne pas rater le patch)

GitHub & co ne va pas régler le premier problème. Aucun process ne le pourra: quand il y a trop de boulot, il faut trier. Et encore, ce tri est bien facilité avec un système de tickets ! Donc même si la bande passante reste la même, elle est sûrement mieux utilisée.

Par contre, le second problème est largement amélioré. Car un email, comme tu l'as dit, ça s'oublie ou se manque facilement. Le ticket, lui il reste là, dans la liste. Si des tickets plus récents sont créés puis résolus, il va redevenir plus visible.

Pour moi il n'y a pas photo: un système de tickets est une énorme amélioration pour gérer les demandes.

Manifestement, les mainteneurs de pkexec n'ont pas lu son blog. Et cela n'a rien de bien surprenant…

C'est un peu dommage de se donner la peine de faire cette analyse, un billet de blog, un mail, et de ne pas se demander pourquoi il n'y a aucune réponse au mail. Mais c'est vrai que la mailing-list ne répond peut-être pas à tous les mails d'inconnus, à cause du spam…

Fait amusant: aujourd'hui c'est via Twitter que cette information a réussi à être repérée. Et c'est vrai qu'une PR (ou MR pour Gitlab) est un peu plus visible et plus pratique !

En fait, peut-être que si ?

Lorsque tu passe de 10 à 30 alertes, et que ton voisin passe de 10 millions à 30 millions d'alertes, on peut se demander si on reste, dans l'absolu, dans un bruit de fond: les attaques augmentent en général, mais continuent de ne pas te cibler toi plus qu'avant.

La question de savoir qui cause quoi (déploiement, robustesse, intérêt financier, méthode de remontée des problèmes, autre) reste entière. Mais ne pas se mettre des oeillères lorsqu'on analyse un problème (qui reste à définir d'ailleurs) c'est toujours bénéfique.

j'ai du mal à voir où il pourrait faire un remove_dir_all

oui, c'est justement une partie du problème… Comment identifier les impacts ?

Bel exemple ici d'un inconvénient d'utiliser des binaires statiques (chose revenue à la mode avec Go et Rust): lorsqu'un bug est découvert dans une dépendance, il est très difficile de savoir ce qu'on doit mettre à jour.

Alors pour les paquets d'une distribution Linux j'imagine que tout sera recompilé avec la nouvelle version de la bibliothèque standard, mais pour le reste (petits utilitaires compilés localement, situation hypothétique d'un binaire commercial qui n'est plus maintenu, etc) c'est un peu le flou artistique…

Je trouve que c'est une saine piqûre de rappel de l'avantage d'avoir un livrable moins monolithique. En attendant, je crois qu'il ne me reste plus qu'à recompiler tous ces fameux petits utilitaires qui veulent remplacer les outils classiques (exa, fdupe, fd, ripgrep…)