J'ai essayé une fois pour installer Python 3.7 sur Debian Stretch parce que j'étais coincé sur Python 3.5 mais ça a pas marché parce qu'il me manquait des libs pour compiler. En tout cas, c'est ce que j'ai compris.
J'ai mal fait ou c'est normal ?
Ca ne fonctionne que pour installer d'anciennes versions sur des distros récentes ?
Je suis maintenant persuadé que tout ce qui est fourni par la distribution ne devrait pas utiliser /usr/bin/env, mais je suis assez persuadé que le reste devrait le faire.
Quand j'ai commencé à utiliser virtualenv, j'étais embêter pour faire tourner le pylint de ma distro pour cette raison (il utilisait Python2 par défaut et mes venvs étaient en Python 3).
J'avais naïvement demandé au mainteneur d'utiliser /usr/bin/env et je m'étais fait jeter. Il avait sans doute raison.
Maintenant, j'installe pylint via pip dans mes venv (automatiquement à la création du venv, avec flake8 et peut-être d'autres trucs) et je pense que c'est la bonne méthode.
Orange Livebox Arcadyan ARV7519 modem firmware version 00.96.00.96.613E appears to be patched against the “/get_getnetworkconf.cgi” flaw that leaks WiFi credentials.
C'est réparé deux jours après l'article, quatre jours après la découverte du problème. C'est déjà ça.
Un peu surpris qu'ils aient communiqué si vite sans laisser le temps à Orage de corriger avant. Mais bon, la faille était déjà connue et exploitée, donc c'était peut-être mieux comme ça.
J'ai pas de réponse générale à apporter, chacun son métier.
Le Big Data, c'est un peu un métier à part, par exemple, et c'est assez costaud sur le plan théorique, il faut un bagage correct en maths. On est plusieurs de ma boîte à avoir essayé de suivre un MOOC big data un peu en dilettante à temps perdu (celui-ci, je crois : https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04006+session10/about) et on s'est cassé les dents. Ça demande des pré-requis et de l'investissement.
Comme dit dans un autre commentaire, savoir utiliser un gestionnaire de version (git par exemple), faire des tests unitaires (pytest en python) et un peu d'intégration continue (analyse statique de code lors des commits, déploiement automatisé quand les tests passent, ce genre de choses), c'est bien aussi. Mais franchement, j'ai regardé un jour la doc de Jenkins et j'ai trouvé ça assez touffu alors sans projet réel sur lequel l'utiliser, je me vois pas l'apprendre. C'est bien de connaître l'idée et je pense pas que ça soit rédhibitoire à l'embauche : ça peut s'apprendre sur le tas au fur et à mesure.
SpaceFox parle de sauvegarde incrémentale, donc oui, je pense que c'est pour l'historique.
Pour l'historique des installations/désinstallations, j'utilise etckeeper qui versionne /etc avec git. Et apt-clone pour conserver la liste des paquets installés. J'ai jamais utilisé apt-clone pour réparer, mais la sauvegarde de /etc c'est vraiment pas mal. En tout cas pour du serveur et pour un utilisateur technique.
Je fais tous les jours à 21h une sauvegarde rsync depuis mon disque principal (2 disques en RAID miroir) vers un autre disque interne. Ce ne sont pas des SSD. Et ma machine date pas d'hier.
Ce n'est pas une sauvegarde incrémentale, juste une synchro.
J'ai jamais constaté d'impact. Mais peut-être que je fais jamais de choses coûteuses à ce moment-là (à part la MAO, je fais rien qui coûte, et je dois faire ça plus tard, probablement…).
Under the GPL, anyone offering the software as a service would have to make the source code available for download. The new terms expand that, requiring them to make the ‘Service Source Code’ available. This means not just the source code for the software, but also the source code for any other software used to serve it from the cloud. This includes “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available,” the SSPL says.
Ça n'impacterait que les logiciels liés à l'exploitation de la DB…
The license won’t apply […] to SaaS companies using it as the basis for their services, the company added.
For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don’t apply to them. Instead, this is about what MongoDB sees as the misuse of the AGPLv3 license. “MongoDB was previously licensed under the GNU AGPLv3, which meant companies who wanted to run MongoDB as a publicly available service had to open source their software or obtain a commercial license from MongoDB,” the company explains. “However, MongoDB’s popularity has led some organizations to test the boundaries of the GNU AGPLv3.”
Ici aussi, je comprends que c'est destiné aux boîtes qui fournissent du Mongo DB en cloud, pas des applis basées sur Mongo DB.
The only substantive change is an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service.
Ce que je comprends de cette phrase c'est que si je développe une appli web à base de MongoDB, je dois la publier sous licence SSPL.
Ça me parait assez gros. On développe une appli web propriétaire pour laquelle on a investi beaucoup de temps dans le développement de couches libres, notamment ODM Mongo Python, et je trouvais le deal assez correct.
Ce modèle me paraît pas mal. On est nombreux à codévelopper des libs Python pour faire de l'API REST et je pense que la plupart des contributeurs développent une appli proprio, mais on essaye de partager le plus possible les bases pour ne conserver que le métier dans le code spécifique à l'appli.
Je ne pense pas qu'on puisse revenir sur le caractère proprio d'une appli comme ça, c'est tout son modèle économique qui est impacté, donc de trois choses l'une
soit j'interprète mal l'annonce
soit un fork fiable va sortir (mais c'est pas moi qui vais le porter)
soit tout ♬ le monde doit changer de base ♬ (<- désolé, pas pu résister)
J'en parle au-dessus. Je l'aurais peut-être déjà installé si c'était dans les dépôts Debian officiels. J'en aurais pas une grosse utilisation, donc je veux pas m'embêter avec la maintenance, sinon ça vaut pas la coup.
Et d'après ce que j'ai lu, c'est pas demain la veille. Même le client n'est pas dans les dépôts, contrairement au client owncloud.
Oui, SSH irait bien pour mon cas. C'est intégré à mon gestionnaire de fichiers (avec gvfs, je pense).
Mais je pense pas que les autres OS fournissent cette facilité.
Et puis pour certaines utilisations, c'est mieux avec des utilisateurs virtuels. Ça serait peut-être faisable avec un système à la gitolite (un utilisateur système, plein de clés SSH), mais là, il faut une bonne couche d'enrobage pour que Mme Michu n'y voit que du feu.
Mouarf, ça serait pas un cadeau pour FB, mais bon, je suis d'accord avec toi. Je crois pas qu'on le fasse, ça a été juste évoqué.
Avec son ancien groupe, le batteur utilisait Dropbox…
J'héberge mes morceaux sur mon serveur, mais j'ai pas d'interface pratique à proposer. FTP, c'est sans doute un gros mot, pour eux.
Je serais bien tenté de mettre un Nextcloud si c'était packagé Debian, quitte à acheter qqs Go de stockage en plus, mais j'ai pas envie de gérer install et surtout maintenance hors APT. Peut-être que je pourrais mettre un truc plus simple avec gestion de droits ultra-simpliste, juste une interface web mono-compte pour exposer un répertoire partagé. Mais bon, il y a pas le confort du client intégré au gestionnaire de fichiers…
Bref, c'est un autre sujet. Mais merci pour ta vigilance.
Il s'agit d'un groupe de musique qu'on est en train de monter.
Je crois qu'ils ont évoqué l'idée de se servir de l'espace de stockage qui va avec le groupe FB pour mettre les compos, mais c'est une autre histoire. Sorti de ça, l'idée n'est pas d'avoir une page, publique ou pas, et un historique, mais juste d'échanger des messages d'orga: on se voit tel jour, tiens écoutez, j'ai mis un nouvel enregistrement.
Ils utilisent ça sur leur téléphone, et il y a peut-être une confusion avec le FB Messenger, c'est pas clair. Je vais clarifier ça avec eux.
Si je comprends bien ton message, je pourrais recevoir des notifications. Si en plus les notifications incluent le contenu du message, c'est pas si pire, sinon il faut se connecter, c'est pénible. Et si en plus je peux répondre en écrivant à une adresse, ça va. Ça va juste bousiller le threading, mais bon… je plaiderai non coupable. Fallait choisir un autre outil.
En fait je cherche à la fois une solution technique pour m'adapter et des arguments techniques (autres que de principe) pour refuser FB. Si c'est inutilisable pour moi parce que pas de mobile et pas pratique du tout parce que pas d'autre utilisation de FB, c'est un bon argument technique, déjà.
Je suis d'accord sur le fond, confidentialité et tout. Mais j'ai affaire à des gens qui s'en branlent et je peux faire avec, dans la mesure où c'est cloisonné (discussion limitées au sujet lié à ce seul groupe).
Techniquement, je trouve ça délirant qu'on se retrouve à imposer à quelqu'un (moi) de passer par une solution technique régressive (FB) là où le courriel fait bien le boulot. Eux ils trouvent ça pratique parce que j'imagine que l'appli FB sur leur téléphone est pratique et le client mail doit être un peu pourri, je sais pas. Je comprends même pas comment ils peuvent être branques au point de pas savoir écrire un courriel et devoir passer par FB pour se parler. Ça me dépasse. M'imposer de devoir ouvrir FB ou installer un client exprès, c'est n'importe quoi. Ne serait-ce que techniquement. Je vais pas passer ma journée à regarder une page FB pour voir si on m'a écrit.
Si j'arrive en proposant une autre solution technique qui nécessite l'installation d'un client dédié (ou la consultation d'un site dédié), je me mets un peu dans la même posture qu'eux, question confidentialité / ouverture mise à part, je leur impose une nouvelle source. Et ça m'arrange pas non plus. Techniquement, faire du polling sur une page FB ou une page Mattermost ça m'emmerde dans les deux cas. Même si je pense que Mattermost fait au moins les notifications par mail et peut-être même possibilité d'utiliser que par courriel, je sais pas.
Bref, la solution alternative à FB qui protège nos échanges on l'a déjà c'est le courriel (même si avec leurs adresses gmail et live, la confidentialité, bof… mais bon), c'est juste que pour décrocher les gens de FB, c'est la croix la bannière et comme je suis pas en position d'imposer autre chose je cherche une façon de m'interfacer avec eux sans passer pour le boulet.
[^] # Re: La prochaine dépêche explique en détail Pyenv
Posté par jihele . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 3.
J'ai essayé une fois pour installer Python 3.7 sur Debian Stretch parce que j'étais coincé sur Python 3.5 mais ça a pas marché parce qu'il me manquait des libs pour compiler. En tout cas, c'est ce que j'ai compris.
J'ai mal fait ou c'est normal ?
Ca ne fonctionne que pour installer d'anciennes versions sur des distros récentes ?
[^] # Re: Propagande /usr/bin/env ?
Posté par jihele . En réponse à la dépêche Python — partie 2 ―Python 2. Évalué à 3.
Quand j'ai commencé à utiliser virtualenv, j'étais embêter pour faire tourner le pylint de ma distro pour cette raison (il utilisait Python2 par défaut et mes venvs étaient en Python 3).
SO: pylint doesn't point to virtualenv python.
J'avais naïvement demandé au mainteneur d'utiliser /usr/bin/env et je m'étais fait jeter. Il avait sans doute raison.
Maintenant, j'installe pylint via pip dans mes venv (automatiquement à la création du venv, avec flake8 et peut-être d'autres trucs) et je pense que c'est la bonne méthode.
[^] # Re: Il mériterait une p'tite dépêche un ou un ptit journal lui ?
Posté par jihele . En réponse au lien XFCE 4.14 released. Évalué à 3.
Content de voir que Xfce sort une nouvelle version. Je l'ai utilisé longtemps.
Je suis passé à Mate du fait de manques de fonctionnalités ou de trucs qui évoluaient pas assez vite ou se corrigeaient pas assez vite.
Je suis tenté de regarder du côté de LXQT mais je suis pas sûr que ça soit assez mûr pour que ressente pas les mêmes petites gênes.
Une dépêche est en cours de rédaction : https://linuxfr.org/redaction/news/xfce-4-14-est-dehors.
# Trucs inutiles
Posté par jihele . En réponse au sondage Quel objet inutile avez‐vous sur votre bureau ?. Évalué à 4.
Un Fort-Boyard en résine qui fait porte-crayon mais j'ai perdu le crayon.
Un livre "Python, les fondamentaux du langage" de 2012 gagné sur DLFP.
Un cahier.
Une boîte de trucs électroniques (RPi, Arduino) liés à un vieux projet.
Un évangile de Luc trouvé par terre.
# Journal
Posté par jihele . En réponse au lien Extensions Firefox inutilisables, explications. Évalué à 4.
https://linuxfr.org/users/claudex/journaux/firefox-ne-peut-plus-utiliser-d-extension
# Liens cassés dans l'article
Posté par jihele . En réponse au lien Quel Debian Project Leader pour 2019 ?. Évalué à 3.
Les liens dans l'article vers les candidats me renvoient une page non trouvée.
# Update 2018-12-25
Posté par jihele . En réponse au lien Plus de 19000 livebox font fuiter leurs identifiants et mots de passe. Évalué à 3.
C'est réparé deux jours après l'article, quatre jours après la découverte du problème. C'est déjà ça.
Un peu surpris qu'ils aient communiqué si vite sans laisser le temps à Orage de corriger avant. Mais bon, la faille était déjà connue et exploitée, donc c'était peut-être mieux comme ça.
# Python rulz!
Posté par jihele . En réponse au journal Huit ans et plus toutes ses dents. Évalué à 9.
J'ai pas de réponse générale à apporter, chacun son métier.
Le Big Data, c'est un peu un métier à part, par exemple, et c'est assez costaud sur le plan théorique, il faut un bagage correct en maths. On est plusieurs de ma boîte à avoir essayé de suivre un MOOC big data un peu en dilettante à temps perdu (celui-ci, je crois : https://www.fun-mooc.fr/courses/course-v1:MinesTelecom+04006+session10/about) et on s'est cassé les dents. Ça demande des pré-requis et de l'investissement.
Python est un outil qu'on peut utiliser dans plein de métiers et ça vaut d'autant plus le coup de l'apprendre que c'est très accessible et super sympa. Je recommande chaudement ce cours en ligne : https://www.fun-mooc.fr/courses/course-v1:UCA+107001+session02/about.
Comme dit dans un autre commentaire, savoir utiliser un gestionnaire de version (git par exemple), faire des tests unitaires (pytest en python) et un peu d'intégration continue (analyse statique de code lors des commits, déploiement automatisé quand les tests passent, ce genre de choses), c'est bien aussi. Mais franchement, j'ai regardé un jour la doc de Jenkins et j'ai trouvé ça assez touffu alors sans projet réel sur lequel l'utiliser, je me vois pas l'apprendre. C'est bien de connaître l'idée et je pense pas que ça soit rédhibitoire à l'embauche : ça peut s'apprendre sur le tas au fur et à mesure.
[^] # Re: Chrome is the new IE?
Posté par jihele . En réponse au journal Microsoft serait en train de développer un navigateur web basé sur Chromium. Évalué à 4. Dernière modification le 04 décembre 2018 à 10:08.
Les critiques de Chrome concernant le respect de la vie privée s'appliquent-elles à Chromium?
[^] # Re: Décorer ses ennemis ?
Posté par jihele . En réponse au lien Un développeur du logiciel VLC et un hacker français nommés chevaliers de l'Ordre du Mérite. Évalué à 5.
Détrompe-toi, le logiciel libre est un sanctuaire où l'on voit manifestants et police s'entraider en laissant de côté leurs différents.
Sur le fond, je suis assez d'accord avec toi qu'il y a parfois une belle hypocrisie. Les décorés n'en ont que plus de mérite.
[^] # Re: Retour d'expérience sauvegarde rsync
Posté par jihele . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
J'ai aussi un disque dur externe USB sur lequel je fais une sauvegarde manuelle hebdomadaire. Je le conserve au bureau.
Il faut pas que la maison brûle le soir où je le ramène pour la sauvegarde…
[^] # Re: Retour d'expérience sauvegarde rsync
Posté par jihele . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
SpaceFox parle de sauvegarde incrémentale, donc oui, je pense que c'est pour l'historique.
Pour l'historique des installations/désinstallations, j'utilise etckeeper qui versionne /etc avec git. Et apt-clone pour conserver la liste des paquets installés. J'ai jamais utilisé apt-clone pour réparer, mais la sauvegarde de /etc c'est vraiment pas mal. En tout cas pour du serveur et pour un utilisateur technique.
[^] # Re: ionice
Posté par jihele . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 3.
Je voulais dire que les devs pourraient le faire, pas Mme Michu.
# ionice
Posté par jihele . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 3. Dernière modification le 15 novembre 2018 à 11:00.
Il y aurait pas moyen dans Mint d'utiliser ionice pour minimiser la priorité de la sauvegarde et pas plomber les autres tâches ?
# Retour d'expérience sauvegarde rsync
Posté par jihele . En réponse au journal Timeshift, l'outil de sauvegarde de Linux Mint 19 : oui mais attention. Évalué à 2.
Je fais tous les jours à 21h une sauvegarde rsync depuis mon disque principal (2 disques en RAID miroir) vers un autre disque interne. Ce ne sont pas des SSD. Et ma machine date pas d'hier.
Ce n'est pas une sauvegarde incrémentale, juste une synchro.
J'ai jamais constaté d'impact. Mais peut-être que je fais jamais de choses coûteuses à ce moment-là (à part la MAO, je fais rien qui coûte, et je dois faire ça plus tard, probablement…).
[^] # Re: Comment ça marche ?
Posté par jihele . En réponse au journal SSPL: All your service are belong to us. Évalué à 5.
Je vois des interprétations contradictoires
https://devclass.com/2018/10/17/mongodb-new-license-cloud-service-providers/
Ça n'impacterait que les logiciels liés à l'exploitation de la DB…
mais pas le code métier.
https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/
Ici aussi, je comprends que c'est destiné aux boîtes qui fournissent du Mongo DB en cloud, pas des applis basées sur Mongo DB.
[^] # Re: Comment ça marche ?
Posté par jihele . En réponse au journal SSPL: All your service are belong to us. Évalué à 6.
Ce que je comprends de cette phrase c'est que si je développe une appli web à base de MongoDB, je dois la publier sous licence SSPL.
Ça me parait assez gros. On développe une appli web propriétaire pour laquelle on a investi beaucoup de temps dans le développement de couches libres, notamment ODM Mongo Python, et je trouvais le deal assez correct.
Ce modèle me paraît pas mal. On est nombreux à codévelopper des libs Python pour faire de l'API REST et je pense que la plupart des contributeurs développent une appli proprio, mais on essaye de partager le plus possible les bases pour ne conserver que le métier dans le code spécifique à l'appli.
Je ne pense pas qu'on puisse revenir sur le caractère proprio d'une appli comme ça, c'est tout son modèle économique qui est impacté, donc de trois choses l'une
[^] # Re: Lien vers le CVE
Posté par jihele . En réponse au journal demain soir on finit tard. Évalué à 8. Dernière modification le 17 octobre 2018 à 10:05.
>=1.9.0and<2.3, c'est les versions de python-cryptography, pas celles de libssh.https://tracker.debian.org/pkg/libssh
stable: 0.7.3-2
stable-bpo: 0.8.1-1~bpo9+1
testing: 0.8.1-1
unstable: 0.8.4-2
Pour le reste, j'ai les mêmes interrogations.
Quant à python-cryptography, on dirait bien que Debian est passée entre les gouttes :
https://tracker.debian.org/pkg/python-cryptography
stable: 1.7.1-3
testing: 2.3-1
unstable: 2.3-1
# Pas de version patchée dans Debian Security?
Posté par jihele . En réponse au journal demain soir on finit tard. Évalué à 2.
Dans Debian, pas de 0.7.6 et 0.8.4 attendra 5 jours comme tout le monde.
https://tracker.debian.org/pkg/libssh
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911149
Ça devrait pas passer dans stable-security, ça ?
[^] # Re: NextCloud
Posté par jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
J'en parle au-dessus. Je l'aurais peut-être déjà installé si c'était dans les dépôts Debian officiels. J'en aurais pas une grosse utilisation, donc je veux pas m'embêter avec la maintenance, sinon ça vaut pas la coup.
Et d'après ce que j'ai lu, c'est pas demain la veille. Même le client n'est pas dans les dépôts, contrairement au client owncloud.
[^] # Re: Les avantages du groupe de discussion sans les inconvénients FB
Posté par jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
Oui, SSH irait bien pour mon cas. C'est intégré à mon gestionnaire de fichiers (avec gvfs, je pense).
Mais je pense pas que les autres OS fournissent cette facilité.
Et puis pour certaines utilisations, c'est mieux avec des utilisateurs virtuels. Ça serait peut-être faisable avec un système à la gitolite (un utilisateur système, plein de clés SSH), mais là, il faut une bonne couche d'enrobage pour que Mme Michu n'y voit que du feu.
[^] # Re: Les avantages du groupe de discussion sans les inconvénients FB
Posté par jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
Mouarf, ça serait pas un cadeau pour FB, mais bon, je suis d'accord avec toi. Je crois pas qu'on le fasse, ça a été juste évoqué.
Avec son ancien groupe, le batteur utilisait Dropbox…
J'héberge mes morceaux sur mon serveur, mais j'ai pas d'interface pratique à proposer. FTP, c'est sans doute un gros mot, pour eux.
Je serais bien tenté de mettre un Nextcloud si c'était packagé Debian, quitte à acheter qqs Go de stockage en plus, mais j'ai pas envie de gérer install et surtout maintenance hors APT. Peut-être que je pourrais mettre un truc plus simple avec gestion de droits ultra-simpliste, juste une interface web mono-compte pour exposer un répertoire partagé. Mais bon, il y a pas le confort du client intégré au gestionnaire de fichiers…
Bref, c'est un autre sujet. Mais merci pour ta vigilance.
[^] # Re: Les avantages du groupe de discussion sans les inconvénients FB
Posté par jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 2.
Merci pour ces infos.
Il s'agit d'un groupe de musique qu'on est en train de monter.
Je crois qu'ils ont évoqué l'idée de se servir de l'espace de stockage qui va avec le groupe FB pour mettre les compos, mais c'est une autre histoire. Sorti de ça, l'idée n'est pas d'avoir une page, publique ou pas, et un historique, mais juste d'échanger des messages d'orga: on se voit tel jour, tiens écoutez, j'ai mis un nouvel enregistrement.
Ils utilisent ça sur leur téléphone, et il y a peut-être une confusion avec le FB Messenger, c'est pas clair. Je vais clarifier ça avec eux.
Si je comprends bien ton message, je pourrais recevoir des notifications. Si en plus les notifications incluent le contenu du message, c'est pas si pire, sinon il faut se connecter, c'est pénible. Et si en plus je peux répondre en écrivant à une adresse, ça va. Ça va juste bousiller le threading, mais bon… je plaiderai non coupable. Fallait choisir un autre outil.
En fait je cherche à la fois une solution technique pour m'adapter et des arguments techniques (autres que de principe) pour refuser FB. Si c'est inutilisable pour moi parce que pas de mobile et pas pratique du tout parce que pas d'autre utilisation de FB, c'est un bon argument technique, déjà.
[^] # Re: Les avantages du groupe de discussion sans les inconvénients FB
Posté par jihele . En réponse au message Envoyer/recevoir des messages Facebook par courriel. Évalué à 10.
Je suis d'accord sur le fond, confidentialité et tout. Mais j'ai affaire à des gens qui s'en branlent et je peux faire avec, dans la mesure où c'est cloisonné (discussion limitées au sujet lié à ce seul groupe).
Techniquement, je trouve ça délirant qu'on se retrouve à imposer à quelqu'un (moi) de passer par une solution technique régressive (FB) là où le courriel fait bien le boulot. Eux ils trouvent ça pratique parce que j'imagine que l'appli FB sur leur téléphone est pratique et le client mail doit être un peu pourri, je sais pas. Je comprends même pas comment ils peuvent être branques au point de pas savoir écrire un courriel et devoir passer par FB pour se parler. Ça me dépasse. M'imposer de devoir ouvrir FB ou installer un client exprès, c'est n'importe quoi. Ne serait-ce que techniquement. Je vais pas passer ma journée à regarder une page FB pour voir si on m'a écrit.
Si j'arrive en proposant une autre solution technique qui nécessite l'installation d'un client dédié (ou la consultation d'un site dédié), je me mets un peu dans la même posture qu'eux, question confidentialité / ouverture mise à part, je leur impose une nouvelle source. Et ça m'arrange pas non plus. Techniquement, faire du polling sur une page FB ou une page Mattermost ça m'emmerde dans les deux cas. Même si je pense que Mattermost fait au moins les notifications par mail et peut-être même possibilité d'utiliser que par courriel, je sais pas.
Bref, la solution alternative à FB qui protège nos échanges on l'a déjà c'est le courriel (même si avec leurs adresses gmail et live, la confidentialité, bof… mais bon), c'est juste que pour décrocher les gens de FB, c'est la croix la bannière et comme je suis pas en position d'imposer autre chose je cherche une façon de m'interfacer avec eux sans passer pour le boulet.
On est bien d'accord que c'est eux qui ont tort…
# Journal traitant de la même info
Posté par jihele . En réponse au lien L'état chinois suspecté d'avoir introduit des puces espionnes dans le design de matériel. Évalué à 3.
https://linuxfr.org/users/regis/journaux/des-puces-espionnes-installees-sur-des-cartes-meres-par-les-chinois