seveso a écrit 188 commentaires

Sélectionner : "accepter les cookies et les données des sites"
Puis: "Accepter les cookies tiers et les données des sites tiers" : jamais

Et installer I don't care about cookies pour ne pas être envahi par les bandeaux demandant votre consentement sur les cookies dont vous vous fichez éperdument.

By using it, you explicitly allow websites to do whatever they want

Du coup, c'est l'inverse de ce que veut l'auteur.

De toute façon les sites feront bien ce qu'ils veulent.

Le meilleur moyen que je connaisse de ne pas laisser de cookies c'est de configurer son navigateur pour les refuser d'office ou bien de les détruire régulièrement. Mais en faisant ça, tu te retrouves systématiquement avec un bandeau envahissant qui t'invite à te prononcer sur l'usage des cookies, alors que tu as déjà choisi de façon définitive et globale que tu n'en voulais pas. Mais ça, le site en question, il ne peut pas le savoir tant qu'il n'aura pas enregistré un cookie dans ton navigateur (hop le serpent s'est mordu la queue).

Donc dans ce cas-là, pour ne plus être ennuyé par ces bannières complètement inutiles, cette extension est vraiment indispensable.

suffit d'afficher le volet latéral

Oui la fonctionnalité est bien là. Mais je suis d'accord avec barmic, l'UI ne la met pas en évidence, ou pas assez.

Et effectivement l'idée de barmic d'avoir une vue du document WYSIWYM me plaît beaucoup.
En tout cas, si LO arrivait à proposer une ergonomie qui rendrait limpide pour tout le monde la séparation du contenu et de la mise en forme ce serait génial.

trop tard pour éditer mon précédent commentaire alors je complète ici

un historique linéaire est plus compréhensible qu'un historique "asynchrone".

En fait j'ai encore du mal à voir à quoi ça pourrait ressembler un historique asynchrone. Intuitivement j'aurais même tendance à ranger git dans cette catégorie "historique asynchrone" et à ranger SVN dans la catégorie "historique linéaire".
Si quelqu'un de pédagogue pouvait éclairer ma lanterne.

Les identifiants incrémentaux de commit posent de gros problèmes, quand on réécrit l'historique

C'est exactement ça qui rend si souvent l'historique d'un projet git difficilement lisible, c'est qu'on peut "réécrire l'historique". Dans SVN on ne peut pas changer le passé (sauf si on est admin du dépôt).

En tout cas j'ai pas l'intention de faire une quelconque comparaison entre SVN et git, je vois assez bien les avantages/inconvénients de chacun. Je voulais juste signaler qu'un historique compréhensible avec git ça nécessite des efforts de la part des humains et que ça n'a absolument rien de systématique.

Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer.

Entièrement d'accord. Sauf que je ne vois pas en quoi git garantit un historique compréhensible. Bien au contraire.
Ayant utilisé SVN par le passé y a un truc qui m'a vite choqué avec git c'est de parcourir séquentiellement un historique avec des identifiants de révisions imbitables et des dates de commit dans le désordre. Je trouve ça moins beaucoup moins lisible qu'un historique SVN avec des identifiants de révision incrémentés et dont les dates sont dans l'ordre chronologique.

Après, avez vous établi un guide des bonnes pratiques, template et un QA ?

Il y a le dépôt example_ynh qui peut servir de point de départ pour packager une nouvelle appli avec un maximum de bonnes pratiques données en exemple.

Il y a également le package_check et le package_linter qui sont des outils de QA utilisés par l'intégration continue pour générer notamment ce genre de dashboard (quelque peu cryptique pour qui n'est pas soi-même mainteneur d'app yunohost) : https://dash.yunohost.org/appci/branch/stable

L'excuse du communautaire ne devrait pas prévenir une certaine exigence.

Je pense qu'il y a déjà une exigence de qualité pour intégrer des apps au dépôt officiel.

Mais il faut bien voir que les applis communautaires ne sont pas installables par défaut. L'utilisateur doit faire le choix d'activer le dépôt communautaire (qui peut-être vu comme un dépôt PPA chez Ubuntu). Et on ne peut pas vraiment reprocher aux dévs de yunohost la qualité d'applis qui ont été développées hors de leur contrôle.

Il faut aussi savoir que l'utilisateur peut installer une app directement à partir d'un URL github, sans passer ni par la liste d'apps officielles, ni la liste d'apps communautaires.

Je viens tout juste de migrer ma brique internet (de yunohost 2.7 vers yunhohost 3.3.1) et puis j'ai lancé le XMPP Compliance Tester et voici le résultat :

Server is running Metronome 3.11.1
Compliance report for brique.trucmuche.net
XEP-0163: Personal Eventing Protocol PASSED
XEP-0191: Blocking Command PASSED
XEP-0198: Stream Management PASSED
Roster Versioning PASSED
XEP-0398: User Avatar to vCard-Based Avatars Conversion PASSED
XEP-0368: SRV records for XMPP over TLS FAILED
XEP-0384: OMEMO Encryption PASSED
XEP-0363: HTTP File Upload PASSED
XEP-0160: Best Practices for Handling Offline Messages PASSED
XEP-0280: Message Carbons PASSED
XEP-0313: Message Archive Management PASSED
XEP-0357: Push Notifications PASSED
XEP-0045: Multi-User Chat PASSED
XEP-0352: Client State Indication PASSED
XEP-0313: Message Archive Management (for Multi-User Chat) PASSED
XEP-0153: vCard-Based Avatar (MUC) PASSED
XEP-0115: Entity Capabilities PASSED
XEP-0065: SOCKS5 Bytestreams (Proxy) FAILED
Informational tests:
XEP-0156: Discovering Alternative XMPP Connection Methods (HTTP) FAILED
XEP-0363: HTTP File Upload (CORS Headers) FAILED
XEP-0077: In-Band Registration FAILED
Contact Addresses for reporting abuse FAILED

Donc on dirait que oui le serveur metronome fourni pas yunohost semble complétement compatible avec OMEMO et MAM.

De ce que j'ai compris, il faut payer pour associer son jid à un numéro

De ce qu'on m'a expliqué la partie payante c'est uniquement pour permettre aux personnes ayant déjà un compte Jabber par ailleurs de pouvoir figurer dans l'annuaire de Quicksy et être ainsi facilement trouvable par les personnes qu'ont déjà ton numéro de téléphone mais qui ne se souviennent pas de ton jabberId.

Mais mes plus gros problèmes avec ça sont :
* l'utilisation d'un identifiant associé à un appareil physique et facilement traçable
* l'envoi des contacts avec une association numéro/nom sans leur demander leur consentement, et sans compartimentation

J'ai les mêmes problèmes que toi à ce sujet mais c'est là où je me dis qu'il faut accepter d'être pragmatique. C'est déjà comme ça que ça fonctionne avec Whatsapp, on ne peut pas empêcher notre entourage de faire fuiter nos numéros de téléphone donc autant que ce soit pour la bonne cause : nous permettre d'échanger avec eux sans installer Whatsapp.

Je pense qu'il y a d'autres façons de faire, plus propres et éthiques, pour la découverte des contacts, et j'ai déjà plusieurs idées en tête.

Si c'est pas top secret je serais très intéressé de connaître ces idées.
Penses-tu pouvoir atteindre le même niveau de simplicité d'utilisation (rien à faire de particulier à part installer une appli) ?

Par ailleurs les centrales à charbon ou pétrolier sont plus dangereux que le nucléaire

Ça tombe bien il ne propose pas de remplacer le nucléaire par du charbon ou du pétrole mais il parle de décroissance.

Je connais Henplus qui n'est pas à proprement parler un explorateur de DB. C'est un client SQL générique en ligne de commande qui supporte n'importe quelle BDD pour laquelle il existe un pilote JDBC (oui Henplus est écrit en Java, mais ça marche bien quand même).

En plus des fonctionnalités classiques il propose Tree View of connected tables qui pourrait t'intéresser.

Si ce n'est pas suffisant, il te permet aussi d'implémenter tes propres plugins à condition d'aimer coder en Java.

Bah oui, planitron, une des armes de Goldorak.
Encore une référence culturelle qui me fait me sentir vieux.

Effectivement, me suis gouré. Je mélange souvent cat et echo. Mais printf c'est bien aussi :)

Un vieil exemple parmi d'autres: Sur Wheezy, l'installation de nmap via apt-get provoque l'installation de x11-common (bug corrigé depuis mais cela reste un exemple parfaitement valide).

Je n'ai pas d'exemple plus récent en tête (et n'en chercherais pas) mais tu sais probablement de quoi je parle ;-)

Oui les bugs de packaging ça arrive... et ça se corrige, comme tu l'as si bien fait remarquer. Mais dans l'ensemble, la gestion des dépendances dans Debian ça marche plutôt bien.

Si un jour il t'arrive à nouveau de devoir utiliser apt install (ou apt-get install sur une wheezy), je te conseille d'utiliser l'option --no-install-recommends, tu devrais la trouver à ton goût.
Je l'utilise systématiquement personnellement. En fait pour ne pas avoir à la taper à chaque fois je la met dans le conf apt comme ceci :

# cat "APT::Install-Recommends "false";" > /etc/apt/apt.conf.d/99norecommends

ils ont réussit à faire un éco-système totalement incompatible avec ce qui existait, le tout en Open Source !

Et?
A ma connaissance rien dans l'open source ne dit qu'il faut être compatible (avec quoi d’ailleurs?), tu peux démontrer le lien que tu sous-entends ?

Pourquoi voudrais-tu qu'il y ait quoique ce soit à démontrer ?
Il a le droit de trouver ça fort de café de la part de Google d'utiliser/contribuer à l'opensource tout en enfermant les utilisateurs.

Je commence par identifier les 2 soldats peu fiables en leur posant des questions simples comme :

• quel est ton nom ?
• quelle est ta quête ?
• quelle est ta couleur préférée ?

Ceux qui ne sont pas dignes de confiance seront automatiquement aspirés dans un gouffre. (cf. https://hooktube.com/watch?v=pWS8Mg-JWSg )

Ça devrait prendre moins de 30 min cette affaire et nous serons alors 3 personnes dignes de confiance pour explorer 4 routes en moins de 1h30.
Ce sera vite réglé.

Typiquement en Java tout le monde est fier de foutre du Yoda partout au cas ou un null se baladerait quelque part sans jamais se demander pourquoi c'est normal que tout puisse être null partout sans aucune raison, indice ou autre... Mauvaise solution à un problème que tu ne devrais pas avoir.

C'est vrai, ça ne sert à rien de prendre des précautions, il suffit de ne pas coder des bugs et d'avoir des tests unitaires exhaustifs.

J'ai le même ressenti sur Homo Deus que toi sur Sapiens.

Homo Deus m'a été conseillé par une amie qui pensait me faire plaisir et je me suis forcé à en lire les 2 tiers. Ça fait quelques mois maintenant que je l'ai mis en pause mais je me suis promis d'aller jusqu'au bout car sait-on jamais je vais peut-être apprendre des choses intéressantes (c'est comme le film "Usual suspects", je me suis forcé à le regarder jusqu'au bout et je n'ai pas regretté).

Le style est plutôt soporifique ce qui n'aide pas à me motiver (c'est peut-être un défaut de la traduction française qui sait ?). Malgré tout l'auteur traite beaucoup de sujets qui m'intéressent et j'aime bien les définitions qu'il donne des religions par exemple, mais dans l'ensemble c'est surtout une succession de banalités et des affirmations sorties d'un chapeau. Par exemple selon lui l'humanité aurait déjà résolu ses 3 plus grandes problématiques que sont la faim, la maladie, la guerre et que la prochaine problématique à résoudre sera de vaincre la mort (on dirait du teasing pour parler de transhumanisme mais je ne suis pas encore arrivé là).
Attention il ne prétend pas que la faim, la maladie et la guerre ont été éradiqués mais uniquement que les solutions à ces problèmes ont déjà été trouvées. Et notamment, selon lui la solution à la guerre c'est l'invention de l'arme nucléaire et son aspect dissuasif. Il prend évidemment de grosses pincettes pour lancer cette affirmation mais quelques pages plus loin il s'en sert comme axiome incontestable pour le reste de son discours.
À partir de là, si on n'est pas d'accord sur l'efficacité de l'arme nucléaire pour empêcher de nouvelles guerres c'est difficile de lire la suite.
Heureusement il passe du coq à l'âne au chapitre suivant.

Bref, je ne recommande vraiment pas ce bouquin, je trouve que c'est effectivement une perte de temps. Lire du Isaac Asimov par exemple donne au moins autant à réfléchir quant à l'évolution de l'humanité et au moins c'est très agréable à lire.
Je vais quand même tenter de terminer ce livre et je reviendrai ici commenter si je change d'avis.

On dirait que tu as déjà eu une mauvaise expérience et maintenant te voilà devenu réticent lorsque tu entends parler d'agilité. Et ce n'est pas moi qui vais te blâmer pour ça.

Personnellement je n'ai jamais eu l'occasion de mettre en pratique de méthodes agiles mais j'avais reçu il y a bien longtemps un formation sur les techniques SCRUMM. Et le peu dont je me souviens c'est que, si on prend du recul sur le vocabulaire nouveau, en fait il s'agirait pour l'essentiel d'appliquer des mini-cycles en V sur des intervalles de temps courts, entre 2 et 6 semaines.
Et c'est loin d'être une hérésie car cela permet d'éviter l'effet tunnel : plusieurs mois de dév pour découvrir qu'en fait on avait mal compris le besoin du client et ce, malgré de magnifiques cahiers des charges et spécifications fonctionnelles.
Avec des cycles courts le client s'implique plus souvent et peut débusquer ce genre de malentendus assez tôt, ce qui limite les dégâts.

En pratique j'ai pu observer de loin de nombreux projets menés en "mode agile" et bien souvent, le choix de mode agile était surtout utilisé comme de la poudre aux yeux du client. Mais j'ai eu aussi des retours positifs de plusieurs projets donc ça me parait absurde de rejeter les méthodes agiles en bloc.
Il faut juste rester méfiant selon la personne qui emploie ces termes.

Dans le même genre j'utilise souvent jetable.org, c'est un peu comme spam gourmet mais sans avoir besoin de créer un compte.

Si tu as ton propre serveur tu peux essayer d'installer disposable-mailbox.

J'ai au moins un exemple : Opodo.

Je regrette terriblement d'avoir utilisé ma vraie adresse email sur opodo.fr car depuis j'ai régulièrement des spams ("Opodo exclusivités") et j'ai suivi au moins 5 URLs de désinscription et je continue de recevoir des spams malgré tout.
Sans parler du fait que dans mon Thunderbird configuré pour afficher les mails en mode texte si disponible rien ne s'affiche dans le cors du mail, j'ai dû aller chercher l'url de désinscription dans le code source en html.

Cela dit, quand j'ai eu affaire à opodo, comme j'ai eu des soucis pour valider un achat et j'ai bien dû faire la manip une dizaine de fois avec la même adresse email, donc si ça se trouve il faut que je me désabonne une dizaine de fois...
Je vais essayer ça mais j'ai peu d'espoir.

Je pense qu'il serait aussi intéressant d'ajouter une entrée DNS CAA. C'est assez simple et ça assure un peu plus la sécurité.

Je découvre CAA et j'ai beau chercher, je n'en vois pas encore l'intérêt. En tout cas du point de vue de la sécurité.
Apparemment les enregistrements DNS de CAA ne sont pas destinés à être consultés par le navigateur Web mais par l'autorité de certification au moment d'émettre un nouveau certificat pour un domaine.

Donc le seul intérêt que je vois pour l'instant c'est d'éviter une erreur humaine chez les employés d'une autorité de certification.

Personnellement je n'ai rien réappris, tout est venu parfaitement naturellement

Je pense que tu es de mauvaise foi en écrivant ça. Pour ma part j'ai dû réapprendre pas mal de choses basiques comme manipuler les logs système, utiliser des timers plutôt que des tâches cron, etc. Mais bon, admettons que tout soit limpide pour toi, dis-toi que ce n'est pas forcément le cas de tout le monde.

Personnellement ça ne me dérange pas de découvrir de nouveaux outils et je ne nie pas que la plupart des fonctions basiques réimplémentées par systemd sont meilleures. Mais j'ai tendance à considérer que maintenir la compatibilité avec l'existant est bien plus important que faire de meilleurs outils.
J'ai longtemps cru que l'informatique et les technologies étaient faites avant tout pour faciliter la vie des humains (et pas seulement les humains passionnés par l'informatique qui ont besoin de vendre leur CV). J'aimerais continuer d'y croire.

Même si des efforts ont probablement été fait pour que systemd soit compatible avec l'existant je constate que c'est loin d'être parfait. Étant un promoteur de l'auto-hébergement il m'arrive parfois de faire du support à distance auprès de personnes pas forcément versées dans l'informatique. Certaines de ces personnes avaient acquis une certaine autonomie en faisant l'effort d'apprendre quelques commandes basiques d'adminsys Linux. Mais l'arrivée de systemd m'a donné beaucoup de fil à retordre et j'ai commencé à découvrir les mille et une habitudes qu'il fallait changer pour que ces personnes regagnent leur autonomie.

Autre cas de figure : les adminsys professionnels qui aiment la stabilité.
Il m'est arrivé de bosser dans de grosses structures où une bonne partie des adminsys sont des personnes qui ont passé l'âge de vouloir suivre "la mode technologique". Je ne te cache pas que certains sont proches de la retraite et n'ont clairement pas la même capacité d'adaptation que les jeunes. On peut penser ce qu'on veut de ces personnes mais il ne faut pas faire l'erreur de les croire stupides.
Discuter avec ces personnes est très enrichissant (mais faut surtout pas entrer trop dans la technique) et tu comprends vite que tu n'abordes pas la veille technologique de la même façon quand tu administres une poignée de serveurs que quand tu as un parc de plusieurs milliers de machines gérées par plusieurs services différents et impliquant des dizaines d'adminsys aux profils techniques différents et éloignés géographiquement. D'autant plus que tout changement technologique implique immédiatement une tonne de documentation d'exploitation à mettre à jour ou à réécrire.
Dans ces cas-là, je comprends qu'on puisse devenir un peu frileux.

Pourquoi est-ce que j'ai toujours l'impression d'être un génie

Peut-être parce que c'est le cas et tu ne le sais pas encore :)
Ou peut-être parce que tu n'as pas encore vraiment essayé de te mettre à la place des autres...

Si j'ai bien compris, le fait que la commande service status burp réponde désormais par un mensonge semble être un effet de bord de la migration de Debian à systemd.
Relis-bien son message, il fait juste un lien avec l'intégration de systemd dans Debian.

(Unicode est compliqué, on n'en a pas besoin, donc c'est de la merde), en toute logique il devrait y avoir une seule locale "en_US".

Ton troll utilise une mauvaise analogie je trouve.

Unicode a le bon goût d'assurer la compatibilité avec ASCII. Ceux qui veulent continuer de tout écrire en ASCII pourront le faire, et un jour s'apercevoir qu'en fait ils écrivent en UTF-8 (donc de l'unicode) sans forcément le savoir.

Passer à systemd en revanche c'est une changement assez radical qui demande énormément plus de sacrifices. Et je peux comprendre que tout le monde n'aie pas envie de réapprendre le métier d'adminsys juste parce qu'il parait que c'est mieux fait avec systemd.

Devuan pourrait intéresser de grosses structures utilisant massivement Debian et où une formation de tous les adminsys à systemd risquerait d'être longue et coûteuse.