seveso a écrit 171 commentaires

quand on aura les numéros de rue partout

Il faut que quelqu'un les ajoute à OSM ces numéros de rue. Pourquoi pas toi ?

Il y a certes un premier pas à passer pour apprendre à contribuer à OSM mais après ça peut devenir une gymnastique routinière.
Personnellement je procède souvent comme ça : je cherche une info dans OSM car j'ai RDV dans un lieu où je ne suis encore jamais allé. Je ne la trouve pas ? Alors tant pis je la cherche ailleurs. Une fois sur place je collecte les infos pour confirmer ce que j'ai déjà trouvé par ailleurs mais aussi d'autres infos. Par exemple si c'est un commerce : les horaires d'ouverture, le numéro de téléphone, le site web. Pour faire rapide et simple en général je prends des photos des différents éléments et une fois à la maison j'ajoute ces infos dans OSM avec mon outil préféré (JOSM en l’occurrence).

En pratique tu peux contribuer de nombreuses manières selon le temps et l'énergie que tu voudras bien accorder à cette tâche.

Si tu as un smartphone Android je te recommande l'appli StreetComplete qui permet de compléter très facilement et rapidement (et aussi de façon un peu ludique) les données OSM déjà existantes. Ça ne permet pas d'ajouter de nouvelles données par contre donc ce n'est pas adapté pour l'ajout des numéros de rue.
Pour ajouter des données à partir d'un smartphone apparemment c'est faisable avec OSMAnd : Contribute to OSM via OsmAnd. J'ai jamais essayé.

[…] si quelqu'un connaît une equivalence libre avec openstreetmap

Y a aussi Maps qui fait navigation offline basée sur les cartes OSM. Beaucoup moins de fonctionnalités que OsmAnd mais il est plus léger et le rendu des cartes est plus fluide je trouve.

un des gros avantages est le fait qu'il soit multiplateforme sans devoir avoir le smartphone connecté et allumé à côté

C'est le cas de Signal aussi. Par contre, un avantage, je crois, c'est la non nécessité de fournir un numéro de téléphone (à vérifier), et la non dépendance à un smartphone (c'est un gros plus).

Dans ce cas, comment fait-on pour désigner un destinataire qui n'a pas de numéro de téléphone ? Est-ce que Signal permet de créer des identifiants autres ?

Pour ma part ça a toujours été un argument pour promouvoir l'appli Conversations. Comme elle est basée sur XMPP elle n'oblige pas à ce que les correspondants aient un smartphone ni même un numéro de téléphone portable. Personnellement je n'ai pas de smartphone et je peux malgré tout échanger avec mon entourage qui est majoritairement sur smartphone.

Le seul avantage de Signal sur Conversations c'était la simplicité d'utilisation au départ. Car contrairement à XMPP il n'y a pas cette étape de création d'un compte puisque le numéro de téléphone fait office d'identifiant. Si maintenant Signal peut s'utiliser sans avoir de numéro de téléphone je me demande comment ça fonctionne.

Et vous enregistrez les documents dans quel(s) format(s) ? OOXML ou ODF ?

Je me demande quel est l'intérêt d'une telle séparation si au final l'entité privée est entièrement contrôlée par l'entité publique. Serait-ce un cas similaire à Stelsia, cette filiale de la SNCF qui pouvait passer des marchés importants sans s’embarrasser avec des appels d'offre publics ?

Je te mets au défi de me montrer 2 logiciels sachant gérer de l'ODT sans casser la présentation.

Ça ne doit pas être facile non plus de trouver 2 logiciels différents qui savent gérer le DocX de la même façon.

Il existe des soft open source qui l'ouvre parfaitement [le DOCX]

J'ai peur que tu t'avances beaucoup.
Je suis presque certains que pour 2 logiciels différents qui supportent le DOCX, on peut créer des documents avec l'un qui auront un rendu différent dans l'autre.
Et pareil pour l'ODT d'ailleurs.

Et contrairement à ce que tu penses même si OOXML a été normalisé ISO (dans des conditions douteuses), il n'en reste pas moins un format extrêmement lourd à implémenter (car chargé par l'héritage des évolutions des formats des précédents formats Microsoft) et donc ce n'est pas un format propice pour faciliter interopérabilité.

C'est justement le deuxième exemple fourni dans l'article non ?

$ nc -t -v 127.0.0.1 60001

Oui mais masquer des éléments avec uBlock Origin c'est bien pour les sites qu'on visite régulièrement. Dans le même genre, les sites que je visite très souvent je les personnalise avec Stylus plutôt.
Mais pour tous les autres sites, c'est cool d'avoir une extension qui s'occupe de faire d'emblée un minimum de nettoyage.

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.