Les licences libres ne donnent pas de droits aux auteurs, mais aux utilisateurs.
Alors d'abord ça dépend des licences libres, il n'y a pas que la GPL dans la vie et encore, je doute qu'elle ne donne pas de droits aux auteurs. D'autres parts, si elles ne donnent pas de droits aux auteurs, cela veut dire qu'un contributeur peut par exemple s'attribuer la paternité de mes contributions sans que je puisse dire quelque chose ?? je ne crois pas..
J'imagine aussi que c'est impossible de retirer des informations personnelles tant qu'on utilise un service qui en a besoin.
C'est ce que j'ai écris. Le RGPD impose toutefois de signaler à l'utilisateur ce qu'il fait de ses données personnelles.
Non, mais le problème, c'est que ces informations sont publiques. À ma connaissance, l'URSAFF ne publie pas les informations personnelles.
Je ne comprends pas, ces données, elles sont publiques ou pas ? ;-)
Quoiqu'il en soit, l'URSAFF échange ces données (une partie au moins) avec d'autres services de l'état il me semble.
Le cas de l'URSAFF et d'autres similaires, c'est que là, les données ne sont pas seulement nécessaire au fonctionnement du service, mais est aussi imposée par des lois (qui t'obligent à donner certaines données personnelles à l'URSAF).
Bref, les obligations imposées par des lois doivent probablement faire parti des exceptions dans le RGPD.
ypiquement, les infos personnelles disponibles par whois sont indispensables pour l'identification du propriétaire d'un nom de domaine
Le WHOIS est encore un cas intéressant, et fait d'ailleurs débat actuellement. Que l'on puisse t'identifier, oui, mais la question est, qui peut t'identifier. Que le registrar auprès duquel tu as réservé ton nom de domaine, stocke dans le WHOIS tes informations personnels, cela peut se comprendre. Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable. Heureusement certains registrar comme Gandi permettent d'obfusquer ces informations (je crois que concrètement, les données restent dans leur base, et dans le WHOIS, elles n'y apparaissent pas)..
Dans git, l'identifiant est le résultat du hashage de ces informations. Si tu les modifies, cela veut dire que l'id ne correspond plus. C'est la manière utilisée dans git pour certifier l'authenticité des informations.
Changer la manière dont c'est fait ou stocké, revient à créer un nouveau format de stockage de Git. Je te laisse en discuter alors avec les mainteneurs de git ;-)
une modification d'un article, ça ressemble à un commit
Oui, mais chez wikipedia, à priori, l'identifiant d'un "commit" n'est pas lié à son parent. Le modifier n'impacte en rien le système. Et puis j'imagine que l'utilisateur est identifié dans une autre table dédié aux utilisateurs, et qu'il n'y a dans le "commit" qu'une référence vers cet utilisateur. Il "suffit" dans ce cas, à priori, juste de modifier un enregistrement dans la base de donnée pour changer le nom en "anonymous1234".
Dans Git, c'est différent, car l'identifiant d'un commit est calculé en fonction de son contenu, c'est à dire en fonction du nom et email de l'auteur, de l'identifiant des commits parents etc.. Changer une information dans le commit, et ça change les identifiants de tous les commits descendants.
Comme je le dis plus bas, en théorie, c'est possible. Mais en pratique, c'est un cauchemar pour les autres utilisateurs, puisque tous les identifiants de commits changent : ça fout la merde chez les développeurs, dans les systèmes d'intégration continue, dans les bugs trackers etc. Et plus le projet est gros, plus tu t'approches de l'enfer. Donc en pratique, c'est juste pas possible.
j'ai du mal à voir comment ce changement peut être légal dans le cadre de la RGPD/GPRD
Dans le cadre d'une participation à un projet open-source, quel qu'il soit, depuis la nuit des temps, implicitement tu acceptes que ton nom et ton email soient publiques. Je ne vois pas comment cela peut être autrement. Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.
Cette identification peut être réèlle (ton vrai nom, et une adresse mail contenant ton nom), ou peut être anonymisée (un pseudo, et une adresse basée sur un pseudo).
Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donné soit publique.
On peut maintenant s'interroger sur la retractation, puisque le RGPD te permet en théorie de supprimer tes données personnelles. Mais dans le cadre d'un dépot git (open-source ou pas), ça devient particulièrement complexe. Certes, en théorie, il serait possible de réécrire tous les commits où ton nom/email apparait. Mais cela revient à créer un nouveau dépôt puisque tous les identifiants des commits créés depuis ta première participation sont changés. Et si il y a besoin de faire ça régulièrement, dans la pratique, cela devient un cauchemar pour les développeurs, puisqu'il faudrait "rebaser" son travail en cours sur un dépôt totalement nouveau, sans parler de tous les outils qui référencent des commits (integration continue, bug tracker…). Bref, en pratique, ce n'est pas possible.
Et fort heureusement, je crois que le RGPD prévoit les cas où tes informations personnelles sont absolument nécessaires au fonctionnement d'un service ou d'une entreprise (vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait").
Bref, la suppression de tes données personnelles dans les dépots git étant impossible, et ce cas d'impossibilité de suppression étant prévu par le RGPD, Gitlab respecte de mon point de vue le RGPD. Donc soit tu acceptes que ton nom/email soit utilisé et tu ne pourras pas faire machine arrière, soit tu n'utilises pas le service.
Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).
Depuis Firefox 57 Quantum (encore lui !), les installations par défaut de Firefox présentent une barre unifiée pour l'adresse et la recherche (cette présentation reste optionnelle pour les profils créés antérieurement).
Elle est optionnelle pour n'importe qui à priori. Il suffit de mettre la préférence "browser.search.widget.inNavBar" à true pour retrouver la séparation entre adresse et recherche.
Mais ma voiture semblait bouder certains morceaux, de manière reproductible, sans que je ne comprenne le problème : on entendait une saccade 3, 4, 10 fois sur certains fichiers
Est ce que lesdits morceaux ne dépasseraient-ils pas une certaine taille de fichiers ? Et est-ce que la coupure arrive à intervalle régulier ?
Je verrais bien la lecture interrompue par l'obligation de lire le fichier morceau par morceau quand le fichier ne tiens pas en entier dans un buffer, avec un code de gestion de ce buffer totalement merdique.
Pour moi, le RGPD, c'est de la poudre aux yeux et n'empêchera en rien la tracking publicitaire, la revente/vole d'information, le profiling… Enfin tout les trucs que nous subissons dès qu'on se connectent à Internet.
Certes, ça n'empeche pas, mais ça devient illégal si l'utilisateur n'a pas donné son consentement. Depuis quelques semaines je vois passer sur twitter des faire-parts de décès de startup dont le business plan reposait sur la revente des données personnelles.
Bref, il va y avoir un peu de ménage, et c'est pas plus mal.
Moi il m'en faut 5 à 10 de plus, le temps que mes scripts Ansible terminent d'installer les paquets nécessaires et de configurer le reste ;-) (Bien sûr, n'est pas compris là dedans le temps de reinstallation du $HOME qui serait nécessaire si ma partition home avait été flinguée).
Pas plus tard qu'hier, j'ai réinstallé mon laptop pro pour passer à kubuntu 18.04 : en 30 min j'étais opérationnel.
D'ailleurs, depuis que j'ai mes scripts Ansible, je ne m'embête plus à faire des upgrades de distro, ça prend moins de temps de tout reinstaller que de faire l'upgrade. Et ça permet de faire le ménage (genre les paquets que j'installe "pour voir" et que j'oublie de virer).
Nous expliquions déjà dans la nouvelle sur GEGL que le traitement en graphe signifie que le traitement d'image non-destructif sera bientôt possible.
Ouaaah. Ça fait des années que j'attends ça ! Je n'ai jamais compris pourquoi ça n'avait jamais été une priorité pour les développeurs de Gimp, alors que c'est ce genre de fonctionnalité manquante qui empêchent clairement de se passer de Photoshop.
Mozilla s’intéresse à l'internet. Voir ses combats sur la privacy, sur la neutralité du net etc..
Et Thunderbird continue a être maintenu. Une équipe a été reformée il y a quelques mois, avec des développeurs payés à plein temps. Voir mon message plus bas.
Tes problèmes de performances sont liés au fait que tu as énormément de message. Au premier chargement, vu le nombre de message, c'est quand même normal que ça prenne du temps. Et sachant que l'interface c'est du XUL (html++) + jS + CSS, ça peut effectivement freezer l'interface par moment.
La comparaison avec les web mail est complètement débile. Un web mail, ça ne charge que les entêtes de quelques messages. Et la recherche dans les messages est faite coté serveur, et qui peut prendre énormément de ressources mais tu ne le vois pas parce que tu n'as pas ces grosses boites grises très bruyantes et qui chauffent beaucoup sur ton bureau. Quand une recherche est faite dans Gmail, c'est un datacenter que tu fais travailler (attention, je ne dis pas que tu fais travailler TOUT le datacenter, mais que tu as à ta disposition la capacité de calcul d'un datacenter).
Thunderbird pourrait, certes, faire du lazy-loading pour afficher la liste de message, ce qui pourrait limiter les freezes au chargement complet d'un compte. Mais pour faire tout un tas d'opération, il doit tout de même télécharger au moins les entêtes de tes milliers de messages : il en a besoin par exemple quand tu veux trier tes messages selon le sujet, l'expediteur etc (en cliquant sur l'un des entêtes de colonne de la liste). Il a besoin aussi d'avoir la liste complète pour qu'il puisse effectuer des recherches, puisque il doit indexer les messages. Le protocole IMAP ne prevoit pas de fonction de recherche, celle-ci ne peut donc se faire coté serveur.
Après tu signales plein de problèmes de messages ou autre. Mais si tu as interrompu brutalement le processus de chargement (ou de suppression de messages etc) en tuant TB, faut pas t'étonner : les fichiers de la base de messages de TB ont certainement été mal fermé, ou partiellement enregistrés. Et donc index et fichiers corrompus… La seule solution simple dans ton cas, c'est de supprimer complètement ton profile (~/.thunderbird) et de reconfigurer ton compte, en étant patient pour le premier chargement.
J'utilise TB depuis de nombreuses années (pour le pro et le perso), et je gère une quinzaine de boites aux lettres, stockées chez différents hébergeurs, pour un total de 5 Go de messages. Je n'ai pratiquement jamais de problème. Sauf effectivement, j'ai eu des problèmes de freeze les quelques fois où j'ai dû recrée un profile et donc dû charger d'un coup mes milliers de messages. La recherche aussi n'est pas si terrible que ça.
Maintenant, par "hygiène" et par souci d'efficacité, je fais le ménage régulièrement dans les messages (suppression pure et simple ou déplacement dans une boite d'archives pour les plus vieux messages). Je classe aussi mes messages dans des sous-dossiers (merci Imap), ce qui évite qu'il y ait des milliers de messages dans un seul dossier. Cela limite donc les temps de chargements, quel que soit le client mail (TB, webmail ou autre) utilisés.
Alors, un point sur la technologie utilisée par Thunderbird.
Disclamer : j'ai longtemps contribué à Firefox, et j'ai, à titre professionnel, développé des extensions pour Thunderbird ou un client mail basé sur TB avec une interface différente.
Le coeur de Thunderbird, c'est le même que celui de Firefox : Gecko. Gecko est un moteur de rendu XML/XUL/HTML + JS + CSS. Il sert tout autant à afficher une interface utilisateur que du contenu web. L'interface utilisateur est donc programmée avec le langage XUL, qui est, si l'on peut dire, du HTML++++. Avec bien sûr du JS pour le comportement et du CSS pour le design.
Donc non, ça n'utilise pas la même UI, mais plutôt les mêmes technos.
Les composants IMAP, POP, SMTP et tout ce qui gère des boites mails, etc sont développés par contre en C++.
En ce qui concerne les threads : tout comme Firefox, l'UI fonctionne dans le thread principal, d'où effectivement des "freezes" si des composants liés à l'interface passent trop de temps à faire des choses. C'est le cas par exemple lorsqu'on configure un compte mail qui a déjà des giga octets de messages : il faut les charger (ça prend du temps, surtout si on a une connexion pourrie), et comme la liste des messages dans l'UI est mis à jour au fur et à mesure du chargement, ça peut effectivement freezer (malgré l'utilisation de techniques de traitements par lot pour éviter de rafraichir l'interface à chaque message chargé).
Dans Firefox, dans le passé, on avait aussi ce problème, en particulier lorsqu'un site faisait de la merde en JS. Mais maintenant que les onglets sont dans des process séparés, ce n'est plus le cas.
Et sinon la bonne nouvelle.
Une équipe de développeurs dédiés à Thunderbird a était recrée il y a quelques mois, et est chapeauté par la fondation Mozilla (et non la corpo, qui s'occupe de Firefox). Pour l'instant ils sont quelques uns dans l'équipe, mais ils sont en processus de recrutement.
Bref, le projet Thunderbird n'est plus abandonné par Mozilla. Les futures chantiers dans Thunderbird va être de refaire des composants comme le carnet d'adresse, d'améliorer l'interface, de faire du nettoyage dans le code, et bien d'autres choses, entre autre de refaire petit à petit l'interface en HTML. En effet, depuis qu'il n'y a plus le système d'extensions XUL dans Firefox, Mozilla est en train de "tuer" XUL et toutes les technos connexes dans Gecko. Par exemple, les "overlays xul" ont disparus, et ils sont en train de faire le ménage et de supprimer XBL, qui est l’ancêtre des web components (le shadow dom a été inventé chez Mozilla, et on l'utilise depuis 20 ans avec XBL ;-) ).
Cette disparition de XUL ne va pas se faire du jour au lendemain, ça va mettre quelques années. Mais les conséquences pour Thunderbird commencent dés maintenant à se faire sentir pour les développeurs. Il va falloir qu'ils suivent le rythme et remplacer l'utilisation des technos qui disparaissent par d'autres.
Non, c'est Linus Torvalds qui a créé git, le 3 avril 2005. Voici les premiers commits qui ont été créé dés qu'il a pu versionner les sources de git avec git, c'est à dire 4-5 jours après avoir débuter le développement de Git.
La première contribution a eu lieu au 49ieme commit, le 12 Avril. Le lendemain, Junio Hamano proposait lui aussi son premier patch. C'est le mainteneur officiel de Git. Quant à Shawn Pearce, il a commencé à contribuer en février 2006.
Suite à ton message, j'ai installé kdevelop et le plugin php fourni dans ma distrib (kubuntu) et voulu essayer de faire du debuggage de php, et je n'ai pas trouvé comment faire. le bouton debug de la barre d'outils me fait un message d'erreur comme quoi le debuggage est seulement supporté pour les applications python.
Il faut installer quelque chose de spécifique ? Comment fait-tu fonctionner xdebug dans kdevelop ?
Sauf si ladite adresse n'est utilisée que pour le site en question, je ne suis pas sûr qu'éviter de laisser une adresse mail sur un site va t'éviter du spam. Les spammeurs ont maintenant tellement d'autres moyens plus pratique de la récupérer (que d'avoir un crawler qui tourne h24), via des listings issue de leaks, de la revente de données entre boites etc…
Et puis de nos jours, les filtres anti-spam fonctionnent plutôt bien coté serveur. Si en plus on utilise un client mail desktop qui va affiner le filtrage comme Thunderbird… Perso, je gère une dizaine de boite mails dans Thunderbird, et je ne vois pratiquement plus de spam dans mes inbox (par contre mes dossiers spam sont bien remplis).
alors très rapidement tu va devoir gérer les mises à jour, la sécurité, les cassages non prévus, etc. toi-même.
Par défaut, Firefox et Thunderbird vanilla se mettent à jour automatiquement. Et pas besoin d'attendre que le paquet de la distro soit mis à jour par le mainteneur du paquet.
Tes arguments ne sont valables que pour les logiciels qui n'incluent pas de système de mise à jour, ou qui sont installés sans passer par un dépôt tiers.
Et pour les cassages, je ne vois pas en quoi un logiciel utilisateur va casser quoi que ce soit. Ok pour une lib vanilla ou un environnment comme KDE ou GNOME que l'on met à jour indépendement de la distro. Mais pour le reste… Comme je le disais dans un autre commentaire, chez moi le paquet libreoffice de la distro est instable, alors que le paquet vanilla fonctionne parfaitement.. Comme quoi..
Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar. Chez moi, ça plante régulièrement, en particulier lors de la sauvegarde, ce qui rend le logiciel inutilisable. Et pourtant ça fait des années que c'est comme ça, parce que bien sûr, à chaque réinstall de mon système, je m'obstine à utiliser les paquets de la distrib. Du coup je me rabat toujours sur les paquets vanilla, et ça fonctionne correctement :)
D'ailleurs je fais de même pour Firefox (et Thunderbird). C'est peut-être la raison pour laquelle je n'ai jamais ces problèmes de lenteur ou de mémoire qu'observent les autres utilisateurs de Firefox.
Bref, je comprend moi aussi que les développeurs de certains logiciels ne veulent pas qu'on build un soft avec des modifications tout en gardant le nom protégé. Pour des logiciels complexes, changer de version de lib peut rendre le logiciel instable.
Maintenant il faut aussi que les développeurs upstream mettent un peu d'eau dans leur vin, en acceptant des patchs qui permettent de corriger des problèmes avec tel ou tel lib ou système. Ça ne peut qu'être bénéfique pour tout le monde.
Sans avoir beaucoup fouillé la doc, il semble que Wapiti se base sur un parser xml (ou html5) pour "naviguer" sur les pages.
Du coup, vu que de plus en plus de sites génèrent des pages (et donc des formulaires) de manière dynamique en JS, je ne vois pas comment Wapiti peut détecter des failles sur ces sites, puisqu'il n'execute pas le javascript. À moins qu'il y ait des modules proposant de surfer avec un navigateur headless (phantomjs, firefox --headless, ou via Selenium..) ?
Yep mais du coup tu ne vérifies pas ce que ton navigateur sert à ses clients. :)
s/navigateur/serveur je suppose ? ;-)
Certes, mais normalement, il n'y a qu'un fichier cert pour le domaine en question sur la machine. Si le serveur ne le trouve pas, il ne voudra pas démarrer, et la vérification par http ne garanti pas que le nouveau est bien pris en compte, sauf si tu mémorises via ton script le nombre de régénération effectuées et mis en place des alertes si ce nombre devient anormalement élevé sur une période de 90 jours.
Qui plus est, sur une infra digne de ce nom, tu as déjà des sondes qui vérifient tes services web, donc qui te remontent les problèmes de connexions foireuses causés par des certificats invalides ;-)
Sinon, dans la même logique, pas besoin de vérifier le fichier : il « suffit » d'exécuter certbot (ou un de ses amis) pour que le certificat soit à jour. :)
Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)
C'est valable si on n'a pas accès au serveur. Mais dans le cas présent, la vérification se fait sur le serveur qui stocke le certificat, donc plutôt que de faire une requête HTTP, autant lire directement le fichier du certificat, ça sera plus rapide
DOMAIN_CRT=/chemin/vers/fichier.crt
ENDDATE=$(openssl x509 -in $DOMAIN_CRT -noout -enddate | cut -d= -f2-)
DAYSREMAINING=$(( (`date -d "$ENDDATE" +%s` - `date -d "00:00" +%s`) / (24*3600) ))
if [ $DAYSREMAINING -lt 5 ]
then
# il reste moins de 5 jours, renouvelons
...
fi
Il n'utilise pas le client letsencrypt "officiel", mais acme_tiny, beaaaaaauuuucoup moins usine à gaz, et qui s'intègre plus facilement dans des infra configurées automatiquement.
Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification. Ce qui était absolument inacceptable pour l'infra que je configurais.
Avec des outils légers comme acme_tiny, il y a juste un alias .well-known à configurer dans le serveur web, et à faire un reload une fois le certificat regénéré. Et optionnellement à ajouter une petite vérification de la validité du certificat dans le script que tu installes en cron.
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 2.
Alors d'abord ça dépend des licences libres, il n'y a pas que la GPL dans la vie et encore, je doute qu'elle ne donne pas de droits aux auteurs. D'autres parts, si elles ne donnent pas de droits aux auteurs, cela veut dire qu'un contributeur peut par exemple s'attribuer la paternité de mes contributions sans que je puisse dire quelque chose ?? je ne crois pas..
C'est ce que j'ai écris. Le RGPD impose toutefois de signaler à l'utilisateur ce qu'il fait de ses données personnelles.
Je ne comprends pas, ces données, elles sont publiques ou pas ? ;-)
Quoiqu'il en soit, l'URSAFF échange ces données (une partie au moins) avec d'autres services de l'état il me semble.
Le cas de l'URSAFF et d'autres similaires, c'est que là, les données ne sont pas seulement nécessaire au fonctionnement du service, mais est aussi imposée par des lois (qui t'obligent à donner certaines données personnelles à l'URSAF).
Bref, les obligations imposées par des lois doivent probablement faire parti des exceptions dans le RGPD.
Le WHOIS est encore un cas intéressant, et fait d'ailleurs débat actuellement. Que l'on puisse t'identifier, oui, mais la question est, qui peut t'identifier. Que le registrar auprès duquel tu as réservé ton nom de domaine, stocke dans le WHOIS tes informations personnels, cela peut se comprendre. Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable. Heureusement certains registrar comme Gandi permettent d'obfusquer ces informations (je crois que concrètement, les données restent dans leur base, et dans le WHOIS, elles n'y apparaissent pas)..
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 6.
Dans git, l'identifiant est le résultat du hashage de ces informations. Si tu les modifies, cela veut dire que l'id ne correspond plus. C'est la manière utilisée dans git pour certifier l'authenticité des informations.
Changer la manière dont c'est fait ou stocké, revient à créer un nouveau format de stockage de Git. Je te laisse en discuter alors avec les mainteneurs de git ;-)
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 9.
Oui, mais chez wikipedia, à priori, l'identifiant d'un "commit" n'est pas lié à son parent. Le modifier n'impacte en rien le système. Et puis j'imagine que l'utilisateur est identifié dans une autre table dédié aux utilisateurs, et qu'il n'y a dans le "commit" qu'une référence vers cet utilisateur. Il "suffit" dans ce cas, à priori, juste de modifier un enregistrement dans la base de donnée pour changer le nom en "anonymous1234".
Dans Git, c'est différent, car l'identifiant d'un commit est calculé en fonction de son contenu, c'est à dire en fonction du nom et email de l'auteur, de l'identifiant des commits parents etc.. Changer une information dans le commit, et ça change les identifiants de tous les commits descendants.
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 10.
Comme je le dis plus bas, en théorie, c'est possible. Mais en pratique, c'est un cauchemar pour les autres utilisateurs, puisque tous les identifiants de commits changent : ça fout la merde chez les développeurs, dans les systèmes d'intégration continue, dans les bugs trackers etc. Et plus le projet est gros, plus tu t'approches de l'enfer. Donc en pratique, c'est juste pas possible.
# Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 10.
Dans le cadre d'une participation à un projet open-source, quel qu'il soit, depuis la nuit des temps, implicitement tu acceptes que ton nom et ton email soient publiques. Je ne vois pas comment cela peut être autrement. Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.
Cette identification peut être réèlle (ton vrai nom, et une adresse mail contenant ton nom), ou peut être anonymisée (un pseudo, et une adresse basée sur un pseudo).
Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donné soit publique.
On peut maintenant s'interroger sur la retractation, puisque le RGPD te permet en théorie de supprimer tes données personnelles. Mais dans le cadre d'un dépot git (open-source ou pas), ça devient particulièrement complexe. Certes, en théorie, il serait possible de réécrire tous les commits où ton nom/email apparait. Mais cela revient à créer un nouveau dépôt puisque tous les identifiants des commits créés depuis ta première participation sont changés. Et si il y a besoin de faire ça régulièrement, dans la pratique, cela devient un cauchemar pour les développeurs, puisqu'il faudrait "rebaser" son travail en cours sur un dépôt totalement nouveau, sans parler de tous les outils qui référencent des commits (integration continue, bug tracker…). Bref, en pratique, ce n'est pas possible.
Et fort heureusement, je crois que le RGPD prévoit les cas où tes informations personnelles sont absolument nécessaires au fonctionnement d'un service ou d'une entreprise (vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait").
Bref, la suppression de tes données personnelles dans les dépots git étant impossible, et ce cas d'impossibilité de suppression étant prévu par le RGPD, Gitlab respecte de mon point de vue le RGPD. Donc soit tu acceptes que ton nom/email soit utilisé et tu ne pourras pas faire machine arrière, soit tu n'utilises pas le service.
# Pourquoi pas ext2 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Partitions ext4 : ne gaspillez plus l’espace disque !. Évalué à 7.
Sur des clefs usb ou autre "petit" stockages externes, je me suis toujours interrogé sur la pertinence d'utiliser ext3 ou ext4. Alors si en plus il est préférable de désactiver le journal comme conseillé ici, pourquoi ne pas proposer tout simplement de formater en ext2 ? Parce qu'à priori, sur une clé USB, ses caractéristiques suffisent (sauf si on a des gros gros fichiers).
# Séparer champs url et champs de recherche
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Optimiser la recherche Web dans Firefox. Évalué à 3.
Elle est optionnelle pour n'importe qui à priori. Il suffit de mettre la préférence "browser.search.widget.inNavBar" à true pour retrouver la séparation entre adresse et recherche.
[^] # Re: bobo tête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche RGPD et logiciels libres pour accompagner les mises en conformité. Évalué à 3.
Tu es sûr ? parce qu'une bonne partie d'entre elles contiennent le nom, voir le prénom, et donc des informations personnelles…
# Histoire de buffer ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Défragmenter une partition FAT32 sous Linux …. Évalué à 4.
Est ce que lesdits morceaux ne dépasseraient-ils pas une certaine taille de fichiers ? Et est-ce que la coupure arrive à intervalle régulier ?
Je verrais bien la lecture interrompue par l'obligation de lire le fichier morceau par morceau quand le fichier ne tiens pas en entier dans un buffer, avec un code de gestion de ce buffer totalement merdique.
[^] # Re: bobo tête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche RGPD et logiciels libres pour accompagner les mises en conformité. Évalué à 3.
Certes, ça n'empeche pas, mais ça devient illégal si l'utilisateur n'a pas donné son consentement. Depuis quelques semaines je vois passer sur twitter des faire-parts de décès de startup dont le business plan reposait sur la revente des données personnelles.
Bref, il va y avoir un peu de ménage, et c'est pas plus mal.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 2.
Moi il m'en faut 5 à 10 de plus, le temps que mes scripts Ansible terminent d'installer les paquets nécessaires et de configurer le reste ;-) (Bien sûr, n'est pas compris là dedans le temps de reinstallation du $HOME qui serait nécessaire si ma partition home avait été flinguée).
Pas plus tard qu'hier, j'ai réinstallé mon laptop pro pour passer à kubuntu 18.04 : en 30 min j'étais opérationnel.
D'ailleurs, depuis que j'ai mes scripts Ansible, je ne m'embête plus à faire des upgrades de distro, ça prend moins de temps de tout reinstaller que de faire l'upgrade. Et ça permet de faire le ménage (genre les paquets que j'installe "pour voir" et que j'oublie de virer).
# traitement d'image non-destructif
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à 4.
Ouaaah. Ça fait des années que j'attends ça ! Je n'ai jamais compris pourquoi ça n'avait jamais été une priorité pour les développeurs de Gimp, alors que c'est ce genre de fonctionnalité manquante qui empêchent clairement de se passer de Photoshop.
[^] # Re: Je comprends pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 6.
Mozilla s’intéresse à l'internet. Voir ses combats sur la privacy, sur la neutralité du net etc..
Et Thunderbird continue a être maintenu. Une équipe a été reformée il y a quelques mois, avec des développeurs payés à plein temps. Voir mon message plus bas.
# normal...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 10.
Tes problèmes de performances sont liés au fait que tu as énormément de message. Au premier chargement, vu le nombre de message, c'est quand même normal que ça prenne du temps. Et sachant que l'interface c'est du XUL (html++) + jS + CSS, ça peut effectivement freezer l'interface par moment.
La comparaison avec les web mail est complètement débile. Un web mail, ça ne charge que les entêtes de quelques messages. Et la recherche dans les messages est faite coté serveur, et qui peut prendre énormément de ressources mais tu ne le vois pas parce que tu n'as pas ces grosses boites grises très bruyantes et qui chauffent beaucoup sur ton bureau. Quand une recherche est faite dans Gmail, c'est un datacenter que tu fais travailler (attention, je ne dis pas que tu fais travailler TOUT le datacenter, mais que tu as à ta disposition la capacité de calcul d'un datacenter).
Thunderbird pourrait, certes, faire du lazy-loading pour afficher la liste de message, ce qui pourrait limiter les freezes au chargement complet d'un compte. Mais pour faire tout un tas d'opération, il doit tout de même télécharger au moins les entêtes de tes milliers de messages : il en a besoin par exemple quand tu veux trier tes messages selon le sujet, l'expediteur etc (en cliquant sur l'un des entêtes de colonne de la liste). Il a besoin aussi d'avoir la liste complète pour qu'il puisse effectuer des recherches, puisque il doit indexer les messages. Le protocole IMAP ne prevoit pas de fonction de recherche, celle-ci ne peut donc se faire coté serveur.
Après tu signales plein de problèmes de messages ou autre. Mais si tu as interrompu brutalement le processus de chargement (ou de suppression de messages etc) en tuant TB, faut pas t'étonner : les fichiers de la base de messages de TB ont certainement été mal fermé, ou partiellement enregistrés. Et donc index et fichiers corrompus… La seule solution simple dans ton cas, c'est de supprimer complètement ton profile (~/.thunderbird) et de reconfigurer ton compte, en étant patient pour le premier chargement.
J'utilise TB depuis de nombreuses années (pour le pro et le perso), et je gère une quinzaine de boites aux lettres, stockées chez différents hébergeurs, pour un total de 5 Go de messages. Je n'ai pratiquement jamais de problème. Sauf effectivement, j'ai eu des problèmes de freeze les quelques fois où j'ai dû recrée un profile et donc dû charger d'un coup mes milliers de messages. La recherche aussi n'est pas si terrible que ça.
Maintenant, par "hygiène" et par souci d'efficacité, je fais le ménage régulièrement dans les messages (suppression pure et simple ou déplacement dans une boite d'archives pour les plus vieux messages). Je classe aussi mes messages dans des sous-dossiers (merci Imap), ce qui évite qu'il y ait des milliers de messages dans un seul dossier. Cela limite donc les temps de chargements, quel que soit le client mail (TB, webmail ou autre) utilisés.
[^] # Re: Mes retours, un peu plus positifs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 10.
Alors, un point sur la technologie utilisée par Thunderbird.
Disclamer : j'ai longtemps contribué à Firefox, et j'ai, à titre professionnel, développé des extensions pour Thunderbird ou un client mail basé sur TB avec une interface différente.
Le coeur de Thunderbird, c'est le même que celui de Firefox : Gecko. Gecko est un moteur de rendu XML/XUL/HTML + JS + CSS. Il sert tout autant à afficher une interface utilisateur que du contenu web. L'interface utilisateur est donc programmée avec le langage XUL, qui est, si l'on peut dire, du HTML++++. Avec bien sûr du JS pour le comportement et du CSS pour le design.
Donc non, ça n'utilise pas la même UI, mais plutôt les mêmes technos.
Les composants IMAP, POP, SMTP et tout ce qui gère des boites mails, etc sont développés par contre en C++.
En ce qui concerne les threads : tout comme Firefox, l'UI fonctionne dans le thread principal, d'où effectivement des "freezes" si des composants liés à l'interface passent trop de temps à faire des choses. C'est le cas par exemple lorsqu'on configure un compte mail qui a déjà des giga octets de messages : il faut les charger (ça prend du temps, surtout si on a une connexion pourrie), et comme la liste des messages dans l'UI est mis à jour au fur et à mesure du chargement, ça peut effectivement freezer (malgré l'utilisation de techniques de traitements par lot pour éviter de rafraichir l'interface à chaque message chargé).
Dans Firefox, dans le passé, on avait aussi ce problème, en particulier lorsqu'un site faisait de la merde en JS. Mais maintenant que les onglets sont dans des process séparés, ce n'est plus le cas.
Et sinon la bonne nouvelle.
Une équipe de développeurs dédiés à Thunderbird a était recrée il y a quelques mois, et est chapeauté par la fondation Mozilla (et non la corpo, qui s'occupe de Firefox). Pour l'instant ils sont quelques uns dans l'équipe, mais ils sont en processus de recrutement.
Bref, le projet Thunderbird n'est plus abandonné par Mozilla. Les futures chantiers dans Thunderbird va être de refaire des composants comme le carnet d'adresse, d'améliorer l'interface, de faire du nettoyage dans le code, et bien d'autres choses, entre autre de refaire petit à petit l'interface en HTML. En effet, depuis qu'il n'y a plus le système d'extensions XUL dans Firefox, Mozilla est en train de "tuer" XUL et toutes les technos connexes dans Gecko. Par exemple, les "overlays xul" ont disparus, et ils sont en train de faire le ménage et de supprimer XBL, qui est l’ancêtre des web components (le shadow dom a été inventé chez Mozilla, et on l'utilise depuis 20 ans avec XBL ;-) ).
Cette disparition de XUL ne va pas se faire du jour au lendemain, ça va mettre quelques années. Mais les conséquences pour Thunderbird commencent dés maintenant à se faire sentir pour les développeurs. Il va falloir qu'ils suivent le rythme et remplacer l'utilisation des technos qui disparaissent par d'autres.
Ça bouge donc du coté de Thunderbird ! \o/
[^] # Re: Célébrité anonyme.
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche La communauté Git en deuil de Shawn Pearce. Évalué à 10.
Non, c'est Linus Torvalds qui a créé git, le 3 avril 2005. Voici les premiers commits qui ont été créé dés qu'il a pu versionner les sources de git avec git, c'est à dire 4-5 jours après avoir débuter le développement de Git.
La première contribution a eu lieu au 49ieme commit, le 12 Avril. Le lendemain, Junio Hamano proposait lui aussi son premier patch. C'est le mainteneur officiel de Git. Quant à Shawn Pearce, il a commencé à contribuer en février 2006.
[^] # Re: Kdevelop
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Quel IDE pour quel langage. Évalué à 3.
Suite à ton message, j'ai installé kdevelop et le plugin php fourni dans ma distrib (kubuntu) et voulu essayer de faire du debuggage de php, et je n'ai pas trouvé comment faire. le bouton debug de la barre d'outils me fait un message d'erreur comme quoi le debuggage est seulement supporté pour les applications python.
Il faut installer quelque chose de spécifique ? Comment fait-tu fonctionner xdebug dans kdevelop ?
[^] # Re: Vous reprendrez bien un peu de spam ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framasoft annonce la sortie de Framasite. Évalué à 3.
Sauf si ladite adresse n'est utilisée que pour le site en question, je ne suis pas sûr qu'éviter de laisser une adresse mail sur un site va t'éviter du spam. Les spammeurs ont maintenant tellement d'autres moyens plus pratique de la récupérer (que d'avoir un crawler qui tourne h24), via des listings issue de leaks, de la revente de données entre boites etc…
Et puis de nos jours, les filtres anti-spam fonctionnent plutôt bien coté serveur. Si en plus on utilise un client mail desktop qui va affiner le filtrage comme Thunderbird… Perso, je gère une dizaine de boite mails dans Thunderbird, et je ne vois pratiquement plus de spam dans mes inbox (par contre mes dossiers spam sont bien remplis).
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 2.
Par défaut, Firefox et Thunderbird vanilla se mettent à jour automatiquement. Et pas besoin d'attendre que le paquet de la distro soit mis à jour par le mainteneur du paquet.
Tes arguments ne sont valables que pour les logiciels qui n'incluent pas de système de mise à jour, ou qui sont installés sans passer par un dépôt tiers.
Et pour les cassages, je ne vois pas en quoi un logiciel utilisateur va casser quoi que ce soit. Ok pour une lib vanilla ou un environnment comme KDE ou GNOME que l'on met à jour indépendement de la distro. Mais pour le reste… Comme je le disais dans un autre commentaire, chez moi le paquet libreoffice de la distro est instable, alors que le paquet vanilla fonctionne parfaitement.. Comme quoi..
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 2.
Il est vrai que je suis sous Kubuntu.
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 5. Dernière modification le 14 février 2018 à 10:38.
Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar. Chez moi, ça plante régulièrement, en particulier lors de la sauvegarde, ce qui rend le logiciel inutilisable. Et pourtant ça fait des années que c'est comme ça, parce que bien sûr, à chaque réinstall de mon système, je m'obstine à utiliser les paquets de la distrib. Du coup je me rabat toujours sur les paquets vanilla, et ça fonctionne correctement :)
D'ailleurs je fais de même pour Firefox (et Thunderbird). C'est peut-être la raison pour laquelle je n'ai jamais ces problèmes de lenteur ou de mémoire qu'observent les autres utilisateurs de Firefox.
Bref, je comprend moi aussi que les développeurs de certains logiciels ne veulent pas qu'on build un soft avec des modifications tout en gardant le nom protégé. Pour des logiciels complexes, changer de version de lib peut rendre le logiciel instable.
Maintenant il faut aussi que les développeurs upstream mettent un peu d'eau dans leur vin, en acceptant des patchs qui permettent de corriger des problèmes avec tel ou tel lib ou système. Ça ne peut qu'être bénéfique pour tout le monde.
# Scanner "statique" : intérêt limité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 2. Dernière modification le 16 janvier 2018 à 13:23.
Sans avoir beaucoup fouillé la doc, il semble que Wapiti se base sur un parser xml (ou html5) pour "naviguer" sur les pages.
Du coup, vu que de plus en plus de sites génèrent des pages (et donc des formulaires) de manière dynamique en JS, je ne vois pas comment Wapiti peut détecter des failles sur ces sites, puisqu'il n'execute pas le javascript. À moins qu'il y ait des modules proposant de surfer avec un navigateur headless (phantomjs, firefox --headless, ou via Selenium..) ?
[^] # Re: Probablement pas mieux mais très répendu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 1.
s/navigateur/serveur je suppose ? ;-)
Certes, mais normalement, il n'y a qu'un fichier cert pour le domaine en question sur la machine. Si le serveur ne le trouve pas, il ne voudra pas démarrer, et la vérification par http ne garanti pas que le nouveau est bien pris en compte, sauf si tu mémorises via ton script le nombre de régénération effectuées et mis en place des alertes si ce nombre devient anormalement élevé sur une période de 90 jours.
Qui plus est, sur une infra digne de ce nom, tu as déjà des sondes qui vérifient tes services web, donc qui te remontent les problèmes de connexions foireuses causés par des certificats invalides ;-)
Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)
[^] # Re: Probablement pas mieux mais très répendu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 3.
C'est valable si on n'a pas accès au serveur. Mais dans le cas présent, la vérification se fait sur le serveur qui stocke le certificat, donc plutôt que de faire une requête HTTP, autant lire directement le fichier du certificat, ça sera plus rapide
[^] # Re: Rien à faire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 3.
Il n'utilise pas le client letsencrypt "officiel", mais acme_tiny, beaaaaaauuuucoup moins usine à gaz, et qui s'intègre plus facilement dans des infra configurées automatiquement.
Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification. Ce qui était absolument inacceptable pour l'infra que je configurais.
Avec des outils légers comme acme_tiny, il y a juste un alias .well-known à configurer dans le serveur web, et à faire un reload une fois le certificat regénéré. Et optionnellement à ajouter une petite vérification de la validité du certificat dans le script que tu installes en cron.