LeBouquetin a écrit 1907 commentaires

Aucun problème de réputation IP n'est insolvable ; tout dépend du temps et de l'énergie que tu as pour le résoudre.

Sur les IPs fournies par des hébergeurs, l'historique qui te précède a un impact et ça ne se résoud pas nécessairement en 1 clic ou 2.

Oui ok ça fait pas rêver, mais le principe des marchés de niche c'est ça justement : ne pas être partout.

Ça n'est pas un détail. Si Firefox devient un navigateur de seconde zone, il sera bien moins écouté au W3C par exemple.

C'est déjà le cas en fait. Et en plus le modèle économique repose sur la (bonne) volonté de son concurrent de le maintenir artificiellement à flot

Déjà le sujet m'interpelle : avoir moins de 2% de parts de marché et être au bord du gouffre sont deux choses décorrélées. On peut avoir des parts de marché conséquentes et être au bord du gouffre, et inversement. Les marché de niche, ça a toujours existé et c'est des pouillèmes de PDM. Mais ça veut dire "accepter d'être sur un marché de niche"

L'article dit ceci :

Firefox se rapproche ainsi dangereusement des 2 % de part de marché en dessous duquel certains sites Web gouvernementaux (américains et britanniques, par exemple) cessent de supporter un navigateur.

Ce qui signifie effectivement que le seuil des 2% est critique … aux États-Unis (et en Angleterre si je suis ce qui est dit dans l'article) mais quid du reste du monde ? Oui ok ça fait pas rêver, mais le principe des marchés de niche c'est ça justement : ne pas être partout.

Mozilla est aujourd'hui en compétition avec Google et Apple … n'est-ce pas juste qu'il faut accepter de perdre cette bataille et s'attaquer à une bataille qui serait adaptée aux moyens de la fondation ? (qui n'ont rien à voir avec les moyens de Google, il faut rester lucide)

Une telle situation pourrait précipiter l'effondrement du navigateur.

L'effondrement n'est pas lié aux 2% mais au modèle économique de la fondation qui est largement tributaire du financement qu'elle obtient … de son principal concurrent.

Le monde du logiciel libre n'aime pas l'idée de "faire de l'argent" mais la réalité c'est que l'argent c'est juste la représentation de la valeur que les gens donnent à ce que l'on fait et le moyen de transférer le fruit de son travail à une autre personne ou organisation.

Trouver un modèle économique viable, c'est la base, qu'on soit une entreprise, une association, un individu (tu veux une belle maison, bah il faut en face le revenu qui permet d'avoir cette belle maison - ou alors faire des efforts sur ton temps libre pour réduire les coûts d'acquisition et d'entretien).

Dans la communauté, le débat est très animé, la question étant de savoir comment Firefox en est arrivé à ce stade.

La question n'est pas tellement de savoir comment on en est arrivé là - ou plutôt comment Firefox en est arrivé là mais où ça peut aller.

La fondation appelle-t-elle à l'aide sa base d'utilisateurs convaincus ? Fait-elle le nécessaire pour que ces utilisateurs mettent la main à la pâte ?

Comme dit par ailleurs : les utilisateurs cherchent d'abord des fonctionnalités. La protection des données en est une, la performance aussi … mais aujourd'hui ça n'a pas l'air d'être les fonctionnalités les plus recherchées.

Innover, c'est le principe pour rester dans la course. La fondation est largement capable d'innover - Rust vient de chez eux, il me semble. Mais aujourd'hui, je ne vois plus d'innovation dans Firefox.

Je fais partie des utilisateurs convaincus et pourtant à chaque mise à jour Firefox ne met à ne plus fonctionner en attendant que je le redémarre. Ça me gonfle mais je suis pour le moment toujours convaincu. Mais je n'ai aucun argument pour dire à mon entourage de passer sur Firefox au lieu de Chrome ou Opéra. Le seul argument que j'ai, c'est "google c'est mal" ; mais un véritable argumentaire se base sur des aspects positifs, pas sur du négatif.

L'article évoque un point intéressant à travers un commentaire obtenu durant l'étude de Wray :

la seule chose qui arrête Firefox en ce moment, c'est Mozilla lui-même. C'est ridicule. Mozilla rapporte un demi-milliard de dollars par an. S'ils ne peuvent pas construire un navigateur Web largement utilisé pour cet argent, il y a quelque chose qui ne va pas

Ça me semble lucide …

J'avais entendu parler d'une distinction chez Nextcloud aussi mais de ce que j'avais compris, c'était plutôt une approche type Redhat (c'est open source mais pas public).

Mais je n'ai pas trouvé d'information confirmant ça.

Oui j'ai la même lecture

Interview croisée du boss de Nextcloud et du créateur de Roundcube : https://nextcloud.com/blog/roundcubes-future-at-nextcloud-an-interview-with-the-founders/

J'aime bien l'idée d'embaucher des gens / développeurs sans avoir de plans pour commercialiser quelque chose.

Sur le papier pourquoi pas, mais alors avec un statut loi 1901, pas avec une structure commerciale.

Cette information m'intéresse particulièrement …

Nextcloud n'est pas libre du sol au plafond ?

L'article dit

Cela marque une nouvelle étape dans la décentralisation informatique à l’échelle mondiale.

Je suis dubitatif, je ne vois pas ce qu'apporte Nextcloud en terme de décentralisation par rapport à ce que permettait déjà Roundcube.

Développer le produit, l'activité en respectant les valeurs du libre : oui.

Ou alors Nextcloud prévoit de faire du marketing pour mettre Roundcube sur le devant de la scène à des endroits où les organisations utilisent aujourd'hui du logiciel propriétaire ou du logiciel centralisé ?

Fonctionnellement, j'avais cru comprendre que SOGo était plus riche (délégation de gestion de dossiers par exemple) - et plus proche de ce que permettent les solutions concurrentes avancées (Microsoft, Bluemind), ce qui me laisse penser que les organisations s'orienteraient plutôt vers ces solutions.

Mais là, justement, ce discours aurait plutôt tendance à éveiller ma vigilance car ça sonne creux (ce qui n'est généralement pas le cas avec Nextcloud)

Ça c'est sûr que c'est un carnage le web. Le business s'en est emparé… Ya qu'à faire un tour en ligne sans bloqueur de pub :-(

Mais c'est aussi un environnement extrêmement complexe si tu veux faire les choses bien. On parlait de cache ; mais si tu veux faire qqchose d'adaptatif, accessible, bien référencé, performant, sexy, …

En tout cas on a bien fait de discuter :-)

C'est pas un comportement nouveau : le support utilisateur ça existe depuis des années et c'est à l'opposé de la pureté qu'on cherche quand on fait de la conception (de site, de logiciel, etc). C'est du "damage control".

Ce que je dis c'est pas que le site est bien et que tout va bien ; ce que je dis c'est qu'il faut critiquer avec un peu d'humilité.

Concernant le cache quand on développe un site on est tributaire de la stratégie des navigateurs. Par défaut on ne fait rien mais le butineurs décide de mettre des trucs en cache. Du coup on peut passer des entête HTTP pour dire "ne met pas ça en cache", ce genre de truc, mais en fait c'est pas unanimement respecté.

Du coup la solution pour avoir un truc qui marche et qui est maîtrisé, c'est :

• de régénérer des urls à chaque mise à jour du contenu pour être certain que le contenu ne viendra pas du cache. Exemple : https://mon.site/JS/all.js?token=abcd. On se fait ch… à développer des trucs pour empêcher le browser de mettre en cache
• comme c'est pourri d'un point de vue performance, on ajoute les entêtes pour dire au navigateur de mettre en cache pendant 1 an, comme ça ça va pas recharger.

Au final on est obligé de réimplanter le mécanisme d'optimisation tout en s'assurant qu'on court-circuite les initiatives du navigateur.

À chaque ajout de ressources il faut être vigilant et forcément il arrive qu'il y ait des ratés.

Donc non, c'est pas un problème de compétence.

C'est un sujet complexe et fragile.

Je comprends que ça fait ch… Mais c'est pas les dev ni le support le problème - en tout cas pas plus que l'utilisateur. (Note : je suis pas concerné par ce problème directement, c'est juste un comportement que je retrouve régulièrement et qui m'agace)

Il a suivi une voie alternative …et la réaction du support montre que ce n’est pas un conseil mais la récitation d’un mantra ou d’une prière.

• le support a identifié que c'est un problème de cache au niveau du navigateur, ou plus exactement qu'on peut contourner le problème en purgeant le cache
• le support sait que purger le cache des autres sites n'a rien à voir mais le support met au point une réponse standard qui permet de résoudre le problème pour tous les utilisateurs, quel que soit leur compréhension et leur dextérité technique
• parenthèse, l'auteur du journal est également incompétent puisque il ne sait pas que l'outil qu'il utilise au quotidien permet de purger distinctement les données site par site, ce qui devrait l'inciter à un jugement un peu moins définitif et à un peu plus d'humilité (paille, poutre, tout ça)
• quand on fait du support on rationalise les solutions et on évite les hypothèses difficiles à évaluer (le niveau de compréhension de l'interlocuteur fait partie de ces sujets) et on ne cherche pas à optimiser la manière de faire mais à maximiser les chances de réussite.

Pour le reste, je te laisse juger de la pertinence du titre et du ton du journal à la lumière de ces éléments.

Ce journal montre qu'en suivant les conseils du support ça fonctionne, non ?

Je voyais la virgule de cette manière :

incompétence des développeurs ou décideurs, qui ne voulaient pas passer du temps à faire du standard compatible.

incompétence des développeurs ou décideurs qui ne voulaient pas passer du temps à faire du standard compatible.

Le sujet est sans doute un peu plus complexe qu'un problème de compétences.

Je pense que le sujet est plus subtile.

Les email tu les perds. Et tu redemandes l'info. Comme c'est dématérialisé personne n'y accorde d'importance - il faut donc que pôle emploi garde une copie.

À partir de là, quel intérêt d'envoyer des documents par email alors qu'on peut proposer qqchose de mieux sur le plan du suivi historique d'un dossier ? Tous les documents sont centralisés et accessibles via un site unique. La conservation des données est assurée par pôle emploi qui n'aura donc pas de litige à gérer parce qu'un chercheur d'emploi a supprimé "par erreur son mail"…

Il ne faut pas prendre les utilisateurs pour des c.. mais il est attendu aujourd'huide tous les services numériques qu'ils protègent les utilisateurs d'eux même.

Ça vaut pour tous les services numériques, des serveurs OVH (souvenez-vous l'hiver mais pas le dernier) aux drive Google (coucou l'actu) en passant par tous les services gratuits ou payants (qui va se retenir de grogner si twitter, linuxfr ou autre perd toutes les données des utilisateurs ?)

REST est un principe d'architecture ; ça peut s'appliquer à des APIs mais aussi simplement au routage d'une application web classique.

REST et API sont orthogonaux, comme REST et JSON ou JSON et API

J'ai l'impression que le terme REST a orienté la lecture de certains utilisateurs qui comprennent que tu veux faire des APIs, mais REST n'est pas spécifique aux APIs - cf la page wikipedia qui parle de Representational state transfer

POST ou GET ?

L'idée derrière une architecture est d'avoir qqchose de carré et si possible le + intuitif possible.

Du coup je suggère d'utiliser :

• GET pour des requêtes en lecture uniquement
• POST pour tout le reste (création, modification, suppression)

Ce principe fonctionne bien si tu es ok d'organiser la navigation via des formulaires (

<form action="http://foo.com" method="POST">
  <button>Supprimer</button>
<form/>

Si tu prévois de faire les choses via des liens <a href="xxx">Supprimer</a> alors il faut utiliser des GET et du coup l'archi serait plutôt :

• GET pour des requêtes en lecture uniquement ou des action simples (exemple : supprimer une entité, activer/désactiver un utilisateur, etc)
• POST pour tout le reste (création, modification)

Routage

À partir de ce qui a été dit au dessus, le routage suivant me semble clair et intuitif :

• GET http://foo.bar/entities pour récupérer la liste
• GET http://foo.bar/entities/<id> pour récupérer une entité précise
• POST http://foo.bar/entities pour créer une entité
• POST http://foo.bar/entities/<id> ou POST http://foo.bar/entities/<id>/update pour modifier une entité
• POST http://foo.bar/entities/<id>/delete pour supprimer une entité

Ce à quoi tu peux envisager d'ajouter des routes du style :

• POST http://foo.bar/entities/<id>/activate pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)

• POST http://foo.bar/entities/<id>/archive pour activer une entité par exemple (en imaginant que tu aies un statut actif/inactif comme pour un utilisateur)

D'une manière générale

• cherche à standardiser ton architecture de routage. si tu mets la suppression en GET car accédé via un lien, alors utilise uniquement POST pour la création et modification et mets toutes les actions spécifiques en GET
• dis-toi que tout ce qui est en GET va rester dans l'historique du navigateur et donc proposé en auto-complétion - donc potentiellement ça peut poser problème d'un point de vue utilisateur (par exemple : re-suppression sans faire exprès car mauvaise URL sélectionnée dans l'autocomplétion de firefox)
• tout ce qui passe en GET est visible sur les intermédiaires. Tu trouves dans les logs Apache / NGINX les routes avec les paramètres GET. Typiquement, ne mets pas de données sensibles en GET (exemple : mot de passe, email, etc)
• les paramètres GET sont généralement exploités pour faire du filtrage, par exemple : http://foo.bar/events/?owner=4&category=birthday&after=2023-10-16T00:00:00
• s'il s'agit de pages accessibles publiquement, les GET sont généralement crawlés par les moteurs de recherche

J'ai fait un petit tour de ce qui me vient à l'esprit, n'hésite pas si tu veux approfondir des trucs.

Merci pour le retour sur le site. Ta formulation est plus fluide, je vais voir pour rectifier ça.

Le service repose sur Dovecot mais je ne saurais pas dire si on supporte les dossiers virtuels. Je vais me renseigner.

l'enjeu de ce commentaire ?

Je voulais dire "L'enjeu du commentaire initial"

C'est le cas de galae.

Mais du coup si vous êtes hébergé chez un prestataire qui vous convient, c'est quoi l'enjeu de ce commentaire ?

De notre côté dans ce cas de figure et parc hétérogène, on déploie

• soit un serveur openmediavault,
• soit un "Tracim NAS" + clients Windows ou Linux qui exploitent soit un accès WebDAV soit TRSync (synchro de fichiers).

Pour la gestion des machines, on configuré selon les attentes client les mises à jour auto + prise en main à distance avec RustDesk je crois.

C'est quoi que tu recherches qui concrètement ? L'accès centralisé et sécurisé aux fichiers ? Une authentification centralisée ? La gestion du parc et des mises à jour ? Un outil de déploiement des configurations genre imprimante, lecteurs réseaux etc etc ?

Les 35 mails par jour, c'est pour la totalité du compte.

Merci pour le retour. Comme pour ma réponse ci-dessus, je vous invite à poser les questions sur l'espace communautaire pour les mutualiser et mutualiser nos réponses (et elles seront potentiellement plus précises).

est-ce que vous envisagez de déployer SMTP-AUTH et IMAPS

Il faudrait que j'en reparle avec l'équipe technique ; comme dit précédemment, la roadmap n'est pas encore très claire

mise à dispo d'une API

Il y a bien une API mais il ne me semble pas qu'elle soit ouverte aux comptes utilisateurs. En tout cas pas encore. Je t'invite vivement à l'évoquer sur l'espace communautaire pour aller dans ce sens (ça me semble une bonne évolution, c'est aussi l'enjeu identifié par les utilisateurs et clients qui nous va nous aider à prioriser les améliorations)

Est-ce qu'il est prévu de pouvoir facilement migrer d'une offre vers une autre (ici Start => Evolution) en cas de besoin ?

C'est effectivement possible et sans douleur (pas de reconfiguration de votre côté : c'est une démarche "contractuelle" et une intervention de notre équipe support)

Merci pour ce retour Cyprien :)

Concernant l'autoconfig dans thunderbird, il me semble qu'on avait testé/validé son fonctionnement. Un petit retour sur l'espace communautaire galae serait le bienvenu pour le support et l'ensemble des clients / utilisateurs !