Je n'ai jamais été un grand adepte d'Atlassian et de leur écosystème, et malheureusement, mes réserves ne se dissipent pas.
Cela fait maintenant six ans que je travaille dans la même entreprise, et je n'ai quasiment jamais été confronté au spam ou au phishing dans ma boîte mail professionnelle.
Nous utilisions en interne Bitbucket, Jira et Confluence. Cependant, étant donné la fin du support en auto-hébergé de ce dernier, nous avons récemment pris la décision, après de longs débats internes, de migrer vers Atlassian en tant que service hébergé.
Personnellement, j’aurai préféré passer sur gitea ou gitlab.
Un mois après cette transition, toute l'équipe a reçu un e-mail de phishing ciblant spécifiquement Atlassian. Normalement, il serait peu probable que toute les e-mails équipes soit touchée par une campagne de phishing, ce qui suggère que notre liste d'e-mails a été revendu.
Bien que nous n'ayons pas de preuves concrètes, on a quand même de gros soupçons à l'égard d'Atlassian.
# Combien d'entreprises...
Posté par Psychofox (Mastodon) . Évalué à 8. Dernière modification le 13 février 2024 à 11:53.
…prennent en compte le coût d'exportation de leurs données dans le choix d'un outil/produit/service en ligne. Très peu j'imagine.
[^] # Re: Combien d'entreprises...
Posté par Micromy (site web personnel) . Évalué à 10.
Ben pourquoi ? Les commerciaux ont assuré aux dirigeants de la boîte que la migration serait "dramatically easy"* grâce a l'"insane well designed process"* qui permet à l'entreprise un gain de valeur incroyable et sans effort. S'ils le disent c'est que ça doit être vrai, non ?
Bon, après ils ne précisent pas quelle entreprise bénéficie du gain…
* désolé pour les anglicismes sur DFLP, j'ai un bingo de la connerie du buzz à remplir…
# Personne n'a lu ...
Posté par Christophe B. (site web personnel) . Évalué à 4.
Personne n'a lu les 250 000 pages de conditions d'utilisation ?
Surtout que cela doit être inscrit en plusieurs langues et de différentes manières…
C'est dommage de la part de cet éditeur, les produits ne sont pas mauvais (j'aime bien confluence) mais petit à petit la politique commerciale est devenu exécrable
[^] # Re: Personne n'a lu ...
Posté par aiolos . Évalué à 8.
Vraiment ? J'arrive pas à piger la plus-value par rapport à n'importe quel moteur de wiki… La recherche est à chier, l'édition pas particulièrement plus puissance qu'ailleurs et la gestion des éditions simultanées pas des plus performantes… Et en plus c'est proprio/SaaS.
Bref, je pige pas, alors si tu as des éléments pour aimer le bordel incontournable, je suis preneur.
[^] # Re: Personne n'a lu ...
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 14 février 2024 à 09:56.
Même remarque ici. Pour moi Confluence c’est une usine à perdre de l’information, parce que le moteur de recherche est une catastrophe, donc si tu n’as pas très bien tout rangé, tu ne retrouves rien…
D’autre part, ils font du forcing pour leur IA partout qu’ils ont réussi à intégrer en 6 mois ; par contre à côté de ça il y a régulièrement des régressions, des problèmes de performances, le WYSIWYG qui fait un peu ce qu’il veut quand il veut, des choix d’ergonomie franchement discutables
Dans leurs produits, ils ont aussi Jira, qui mériterait sa place dans Wikipedia à la section : « Usine à gaz : exemples en informatique ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Personne n'a lu ...
Posté par Psychofox (Mastodon) . Évalué à 7.
Les produits Atlassian s'apparentent plus à une punition qu'une utilisation de part leur latence/lenteur. On dirait des simulateur de pc qui swappent.
Après si tu sors toutes les fonctionnalités de jira tu ne trouves pas ou peu d'équivalent. T'as pleins d'outils qui couvrent une partie des fonctions (et ce serait souvent suffisant pour tout le monde) mais une fois que les gens ont pris l'habitude d'avoir n'importe quel workflow ils ne peuvent plus s'en passer.
Par contre oui confluence est plus facilement remplaçable (en terme de fonctionnalités), pour qui a envie de se taper la migration.
[^] # Re: Personne n'a lu ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Je fais une réponse globale a vous trois :
La recherche elle fait le job sans plus…
L'édition elle me convient très bien, copier/coller d'image, gestion des tableaux, macros intéressantes comme 'Sommaire' / 'Affichage des Enfants' / 'Saisie de Code' etc …
L'édition PDF est pas mal foutu a condition de programmer une macros pour la gestion des sauts de page
Et fin du fin insertion de graphique Draw.io intégré dans le produit.
Bref je l'utilise quasiment tout les jours et cela me permet de générer de jolie documentation.
Mais de la a dire que c'est une usine a perdre … non pas d'accord
je ne suis pas pour les produits proprio mais j'aimerais trouver une équivalence dans le libre (si j'avais plus de temps je m'y mettrai … ou je chercherai)
Il y a quelques années j'avais rechercher une équivalence, car justement Atlassian arrêtais les versions serveurs locaux
Il y a Tracim ( https://demo.tracim.fr/ui/login ) qui , dans mes souvenirs est très bien et qui maintenant a peut être rattrapé voir dépassé Confluence, mais la je suis dans une grosse structure qui a les moyens de se payer confluence et c'est pas moi qui décide des produits à utiliser.
Après Confluence donne une impression de produit pas fini, moins fignolé et dont le but n'est pas d'être utilisé et il est clairement conçu pour être vendu et rendre captif.
Export Difficile, pas d'export LibreOffice etc … petites fonctionnalités utiles qui manquent.
Mais ce n'est pas un "mauvais" produit
[^] # Re: Personne n'a lu ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Pour la difficulté d’export, c’est plutôt qu’il n’y a rien de natif… et cela se comprend parce-que le choix a été fait d’avoir une grosse API et laisser chacun faire à sa sauce. Du coup, tu as des extensions (payantes mais ce n’est pas la question, c’est surtout qu’un truc intégré risque de casser le modèle économique lié au « marquet » je pense.) ou tu écris les tiennes. En général, pour tirer le meileur de Confluence et Jira, il faut mettre les mains dans le cambouis (hélas peu de grosses boîtes utilisant ces outils ont une équipe de devs dédiés, va comprendre) ou dans la poche. D’où l’impression que ce n’est pas si bien fini.
L’export PDF aussi est de mon point de vue plus une démo qu’autre chose (encore cet aspect non fini), tant qu’on ne prend pas le temps de faire de la configuration (pas qu’une macro pour gérer veuves et orphelin, mais par défaut les styles de la page ne sont pas conservés —ça se configure plus ou moins aisément— et les métadonnées sont limités —et surtout il n’y a pas les marques-pages— etc.)
Tiens, j’ai vu qu’il y a un export Word… minimaliste aussi mais très propre (s’utilise aisément dans LibO, mais il est possible de créer un truc dédié en mettant les mains…)
Je comprends qu’on puisse ne pas aimer (perso, ce qui me gêne le plus est qu’il y ait une pseudo syntaxe wiki mais que ça ne fonctionne qu’en wysiwyg et donc qu’on ne puisse pas rédiger « offline » et donc faire de l’import manuel au lieu de ressaisie) De là effectivement à taxer d’usine faut n’avoir pas vu les pseudo alternatives que choisissent certaines entreprises du CAC40 (entre les documents µS dans un partage… ou le Sharepoint… je ne sais plus à quels saintes me vouer.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Personne n'a lu ...
Posté par Psychofox (Mastodon) . Évalué à 5.
Nous on met la doc dans des repos git et elle se génère automatiquement avec mkdocs via notre outil d'integration continue à chaque commit.
Personnellement je préfère le diagram as code avec mermaidjs mais certains collègues utilisent quand même drawio, la plupart utilisant le plugin pour vscode.
[^] # Re: Personne n'a lu ...
Posté par Psychofox (Mastodon) . Évalué à 3.
On me dirait: mais ça c'est pour les dev et il faut comprendre git mais n'importe qui peut éditer des fichiers markdown dans une forge avec un éditeur intégré qui commit automatiquement. J'irais même jusqu'à dire que bitbucket est un meilleur moteur de wiki que confluence!
[^] # Re: Personne n'a lu ...
Posté par cg . Évalué à 3.
De mes souvenirs (~ 2017), Confluence était pas mal. L'intégration avec Jira et le fait d'avoir des éléments sémantiques et dynamiques (les todos, les checklists, les refs de ticket, les requêtes) en faisait un truc assez unique. Maintenant y'a la même chose dans Notion, Google Docs et sans doute d'autres wikis…
Si tu aimes les wikis et Drawio, alors sache que WikiJS et Bookstack gèrent nativement Drawio (et donc indirectement Mermaid). Bookstack a ceci de particulier qu'il impose de ranger sa doc comme une bibliothèque : étagères, livres, chapitres, pages. Ça semble contraignant mais ça force à se structurer. Du bonheur pour les bordéliques, perso j'aime bien :D.
[^] # Re: Personne n'a lu ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
je viens de tester Bookstack c'est pas mal du tout
Content de voir que le libre a fait du chemin …
Merci pour l'info
# son altesse sérénissime
Posté par steph1978 . Évalué à 2.
Société par actions simplifiées ?
Statistical Analysis System ?
À la lecture, je pense que le post parle de SaaS, Software as a service.
[^] # Re: son altesse sérénissime
Posté par syj . Évalué à 2. Dernière modification le 13 février 2024 à 13:29.
Je confirme , je me suis trompé.
Je fais en général beaucoup fautes mais c'est encore pire que je suis énervé.
Trop tard pour changer.
[^] # Re: son altesse sérénissime
Posté par gUI (Mastodon) . Évalué à 5.
Corrigé, merci.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: son altesse sérénissime
Posté par spell (site web personnel) . Évalué à 0.
Peut-être que c'était un jeu de mot avec Son Altesse Sérénissime pour insister sur la souveraineté d'Atlassian ?
# Offre DataCenter
Posté par olivierfr . Évalué à 4.
Loin de vouloir jouer au commercial Atlassian, il existe à ma connaissance l'offre DataCenter qui remplace l'offre Server (dont le support s'arrête dans quelques jours). Donc il est encore possible d'auto-héberger les produits Atlassian. Après le coût n'est pas négligeable et je peux comprendre que le choix ne soit pas évident.
# Migrer vers XWiki
Posté par raphj . Évalué à 10. Dernière modification le 14 février 2024 à 02:15.
Rester sur Confluence, ça permet de garder le contenu et de ne pas reformer tout le monde à un nouvel outil. C'est un choix naturel.
Mais les nouveaux tarifs et les changements de conditions liées à l'auto-hébergement ne conviennent pas à tout le monde. Beaucoup d'organismes migrent en ce moment vers XWiki et je travaille en ce moment à quasi plein temps sur ces migrations, notamment et en particulier sur les outils de migrations et sur l'accompagnement des clients sur l'aspect migration. Je me retrouve soudainement expert du format d'export Confluence malgré moi. Ou plutôt, comme écrirait le collègue qui a le plus travaillé sur ce code, "format" (avec les guillemets).
Si ta boite venait à revenir sur sa décision de passer au cloud d'Atlassian, c'est une solution possible, libre et auto hébergeable. On accompagne ces migrations au besoin. C'est surtout nécessaire pour la migration de gros wikis. Et on peut former les gens.
Je peine à imaginer une migration vers GitLab ou Gitea, c'est tellement différent… Oui, il y a une fonction de wiki sur ces outils, mais c'est beaucoup plus léger. J'imagine bien commencer une base de connaissances from scratch avec ça, surtout si c'est déjà en place, mais vous utilisez Confluence et ça fait tellement plus. Une migration vers GitLab ne peut probablement fonctionner sans perdre du contenu que si vous avez une utilisation ultra basique de Confluence sans trop utiliser de macros, le système de permissions, etc. Et aussi, si vous avez des outils pour transférer le contenu vers ces plateformes. Migrer vers XWiki, ça ne marche pas trop mal parce que :
Dans tous les cas, je ne peux qu'espérer pour ta boite qu'elle fera le choix de récupérer le contrôle de sa base de connaissance (avis perso : idéalement libre, idéalement hébergé chez vous), peut importe l'outil.
Je fais un peu de pub, difficile de résister, c'est pile dans mon quotidien du moment :-)
[^] # Re: Migrer vers XWiki
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Je ne saurai parler pour cette entreprise, mais je pense que la question de GitLab n’est pas par rapport à Confluence mais plutôt par rapport à BitBucket et éventuellement Jira (si ça ne fait que des tickets et Epic liés aux codes.)
Sauf si XWiki fait aussi forge Git…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Migrer vers XWiki
Posté par raphj . Évalué à 4. Dernière modification le 14 février 2024 à 07:42.
Ah oui :-)
Il y a aussi OpenProject comme alternative à Jira, en général les gens ont des utilisations complexes de Jira pour lesquelles GitLab peut être un peu léger.
On utilise malheureusement beaucoup Jira, on utilise déjà GitLab pour l'hébergement des projets clients et pour certaines choses pour lesquelles on utilisait Jira, et on est en train d'évaluer OpenProject pour d'autres usages.
Au secours xD non, je ne parlais que de Confluence.
# Phishing ou spam ?
Posté par Ant . Évalué à 4.
Vous avez reçu des e-mails de phishing ou de spam ?
Si c'est du spam, Atlassian aurait donc revendu vos e-mails à une autre société souhaitant faire la promotion de ses produits, ça serait possible bien qu’illégal, à la limite ils auraient donné vos contacts à une filiale ou à une société du groupe. C'est tout aussi illégal depuis RGPD mais beaucoup de boîtes l'ont fait même encore récemment. Mais je vois mal Atlassian faire ce genre de choses, ils sont bien connus dans le secteur et à mon avis ils n'ont pas besoin de ça. En plus,leurs utilisateurs sont les utilisateurs des DSI, pas trop le genre à apprécier ce genre de manoeuvres.
Si c'est du phishing, c'est autrement plus grave. Ils auraient vendu vos e-mails à des groupes crapuleux, c'est passible de prison. Je crois assez peu à ce scénario également.
Je pense plutôt que c'est un stagiaire qui est parti avec le fichier, un membre de la RH qui s'est envoyé le fichier sur son ordi perso pour travailler le week-end et qui se l'ai fait pirater ou un autre scénario du même genre.
En tout cas, confluence je le trouve chez tous mes gros clients, je ne suis pas complétement fan mais c'est correct.
# Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 7. Dernière modification le 14 février 2024 à 09:00.
Ce que je trouve de vraiment génial chez Atlassian, c’est ce que j’appelle la recherche convergente (il existe peut-être un terme standard, mais je ne le connais pas).
Ça permet de se passer d’arborescence et c’est basé sur les étiquettes : quand on clique sur une étiquette, Confluence renvoie la liste des pages portant ladite étiquette MAIS AUSSI ET SURTOUT la liste de toutes les étiquettes de ces pages. Et cliquant sur une deuxième étiquette, ça s’affine : on obtient les pages portant au moins ces étiquettes et la liste des étiquettes associées.
Résultat, avec un bon étiquetage, on retrouve la page voulue en moins de 5 clics.
Je rêve de voir ce principe de recherche intégré dans un système de fichier : plutôt qu’un chemin physique, j’aimerai que mes fichiers possède un chemin thématique.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Jean Gabes (site web personnel) . Évalué à 5.
Oula gros sujet traité maintes fois sur les filesystem, une vraie arlésienne. Le gros soucis: faut bien ranger sa chambre pour que ça marche.
Donc soit les applications le font en auto, soit c'est mort (un utilisateur moyen a déjà du mal avec un simple arbre, alors un système à X dimensions…). Et pour que les applis le fassent en auto faut que le truc soit -très) largement déployé, mais ça sera pas le cas sans appli. Et hop, problème insoluble.
En bonus: faut que les applications se mettent d'accord sur les dites étiquettes. Et là ça va être la guerre absolue en terme de normalisation :)
Bref, pas facile.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 2.
Je ne comprends pas en quoi c’est plus compliqué qu’un chemin physique !
Soit un fichier toto à ranger, le nom du fichier sera :
- /dossiera/dossierb/toto pour un rangement physique
- :thèmea:thèmeb:toto pour un rangement thématique (à noter que :thèmeb:thèmea:toto mène au même fichier).
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Tonton Th (Mastodon) . Évalué à 5.
Il me semble que BeOS faisait quelque chose dans ce genre il y a trente ans…
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Psychofox (Mastodon) . Évalué à 4.
Il n'y a qu'une petite catégorie de personne pour lesquelles le rangement est une vrai pathologie qui étiquettent toutes les pages/documents correctement.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 5.
Simplement parce que ça n’est pas obligatoire !
Si avant de « ranger » un fichier une interface nous demande (voire suggère) les thèmes à appliquer à un fichier, alors chaque fichier sera « correctement » rangé.
Si par facilité, l’utilisateur choisit de « mal » ranger, ben il aura du mal à retrouver ses fichiers !
Et s’il préfère un fourre-tout (un unique thème « fichier ») pourquoi pas ?
Je pense que ceux qui auraient du mal à étiqueter ont déjà du mal à classer leurs fichiers : ceux-là ne verraient pas la différence.
Ce qui est dommage, c’est qu’au prétexte que certains rangent « mal » leurs fichiers, on ne pense pas à ceux qui pourraient bénéficier d’un système bien plus ergonomique que l’actuel.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 14 février 2024 à 14:31.
97% des gens ajouteraient l'étiquette #foo juste pour que le dialogue soit satisfait. Pour pallier à ça j'ai vu une moultitude d'outils métiers qui tentaient d'interdire le champ libre pour avoir des catégories fixes mais tu finis invariablement par tomber sur un truc qui en satisfait aucune et pourrir l'indexation.
Manifestement non puisque la fonction d'étiquetage/mot clés existe dans confluence et dans la plupart des wikis et outils de documentation.
Je dis juste que pour que ça marche bien il faut que tout le monde joue le jeu et que le commun des mortels n'a pas le zèle nécessaire pour que ça se fasse.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ce n’est pas une question de zèle, mais juste que les gens s’en foutent (de juste un peu bien faire leur taf quand on est dans le cadre pro) et sont en mode « vas-y comme je te pousse (et fais pas chier et file moi mon oseille à la fin du mois) »
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par aiolos . Évalué à 4.
T'as pas l'impression de
chier surte montrer condescendant avec tous ceux qui n'ont pas les mêmes pratiques que toi, là ?En fait, c'est l'éternel débat entre les bordéliques et les maniaques qui tente de prendre en otage tous ceux entre ces deux extrêmes du spectre…
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Non, la condescendance est de dire que les gens qui font un minimum de rangement font du zèle. Et je dis bien minimum, pas d’être maniaque. De même, je constate qu’il y aussi des gens qui s’en foutent sans porter de jugement.
Le seul hic ça va être quand on doit travailler en groupe : il faut se mettre d’accord sur un certain nombre de règles et il faut que tout le groupe joue le jeu. En dehors de ça, je m’en tape royalement de ce que chacun fait chez lui et n’ai pas de souci avec la diversité des pratiques personnelles.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Psychofox (Mastodon) . Évalué à 3.
Ça tombe bien sur de la doc je n'ai jamais vu aucune équipe s'accorder là-dessus. Le seul endroit où j'ai vu de l'étiquetage imposé c'est sur des trucs comme des resources d'infrastructures en ligne comme AWS ou Azure.
Et l'erreur étant humaine, sur lesdites resources, on est quand même obligé d'avoir un programme qui vient taper sur toutes nos resources pour vérifier un certains nombre d'étiquettes obligatoires sont bel et bien renseignées. On devrait se dire que c'est inutile avec de l'infra as code mais à priori pas.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par barmic 🦦 . Évalué à 2.
Personnellement je suis incapable de ranger. Si je range d'une façon, à mon prochain accès je trouverais incohérent mon organisation et idem si je réorganise encore. Je lis des livres et conseils, mais rien y fait jusqu'à présent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
En même temps, ne pas ranger n’est pas un vraiment un problème …pour soi :) Pour préciser ma pensée, beaucoup s’astreignent au rangement et ne s’y retrouvent pas vraiment : en fait c’est souvent un héritage de notre éducation/enfance :s Mais le plus important, pour soi, est qu’on se sente bien (j’en connais qui sont épanouis dans leur bazar et je trouve ça plus important que de se prendre la tête à mettre de l’ordre pour plaire aux autres) et qu’on s’y retrouve (pour moi, à partir du moment où tu sais retrouver ce que tu cherches c’est que c’était rangé …juste que tout le monde n’a pas la même façon d’ordonner ses choses et sa vie.)
Par contre, en entreprise il faut se plier aux règles communes établies. Là le minimum syndical est d’utiliser le système de classement en place (donc pas besoin de se prendre la tête à innover mais juste avoir la correction de ne pas ignorer ce qui est en place.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par groumly . Évalué à 3.
Y’a beaucoup de fichiers dans un système de fichiers, et tous ne sont pas créés en mode interactif (genre fichiers téléchargé par une appli, ou zip décompressé, ou config auto générée, fichiers de logs, core dump, ce genre de choses). Un système basé exclusivement sur les tags veut dire que beaucoup (la majorité même) de fichiers serait impossible à trouver soit par manque de tag, soit perdu dans le bruit de 200 000 fichiers ayant le même tag. Et c’est sans compter tous les outils qui s’attendent à trouver des fichiers spécifique à des endroits spécifiques, on va pas créer un tag par fichier dans /etc.
C’est pas un système qui marche au quotidien en mode exclusif.
En mode hybride par contre, à savoir système de fichier traditionnel enrichi avec des tags pour ce que l’utilisateur veut spécifiquement tagger, ça marche très bien. macOS fait ça depuis plus d’une décennie, ptetre même plus de 15 ans. Tu tagges ce que tu veux tagger, le Finder te sort ce que tu veux. Tu peux tagger des dossiers et pas t’emmerder à tagger chaque fois dans cette arborescence, ou juste tagger des fichiers individuels. Y’a techniquement un support pour la ligne de commande, mais ça a pas l’air top moumoute, je pense parce que le système de tag se prête mal à la ligne de commande en règle générale.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 1.
Je ne vois pas en quoi il serait plus difficile d’affecter à un fichier généré un chemin thématique qu’un chemin physique !
Dans les deux cas il s’agit d’affecter d’associer à un fichier une chaine de caractères.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 3.
Le soucis c'est UN.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 1.
Je ne comprends toujours pas : j’espère que le développeur de l’application sait comment ranger les fichiers de celle-ci !
Quant à l’utilisateur final de ladite application, il se fiche
un peutotalement du rangement des fichiers « techniques », il faut seulement qu’il puisse retrouver ceux produits par l’application pour lui, pour lequel l’application devra lui demander de choisir un chemin.« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 4.
il faut gérer les cas d'écrasement ou non du fichier précédemment généré,
que faire si plusieurs fichiers se présentent avec le même chemin sémantique ?
Je fais des photos de la montagne en Juin, faut il écraser les autres? N'en garder qu'une seule?
Un système de fichier traditionnel te garanti 1 chemin => 1 fichier, tu peux même avoir 15 chemin => 1 fichier
Un système sémantique peut vite devenir galère; par exemple un fichier de conf, si un autre fait juste une copie (pour backup), et ce qu'on copie les tags qui vont avec? Et comment va se comporter l'appli avec 2 fichiers qui correspondent au tags? elle prends le plus récent? elle refuse ? Et quid de l'attaquant qui va rajouter un fichier avec les même tags ?
Si toi en tant qu'humain tu es capable de déterminer ce qu'il te faux, il est nécessaire que le programme puisse le faire de manière fiable, sécurisé, et sans loupé.
Bref si une surcouche sémantique peut être pas mal, il y'a des points à prendre en compte qui font que c'est loin d'être simple; et au final il faudra quand même savoir comment fonctionne le système de fichier traditionnel si tu veux administrer.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 1. Dernière modification le 15 février 2024 à 10:12.
Comme écrit plus bas, je propose que le système se base sur un chemin ordonné pour garantir l’unicité d’un fichier :
- chemin physique : /dossiera/dossierb/toto
- chemin thématique : :thèmea:thèmeb:toto
Une fois cela posé, les fichiers se gèrent exactement de la même manière : il ne peut y avoir 2 fichiers avec le chemin.
Ensuite c’est le créateur du fichier qui choisit le chemin (comme actuellement); Pour les fichiers « techniques » : c’est le développeur qui choisit le chemin, pour les fichiers utilisateur, c’est l’utilisateur qui choisit. Dans tous les cas, un fichier ne risque pas d’avoir plusieurs chemins, pas plus que dans rangement physique.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 3. Dernière modification le 15 février 2024 à 10:32.
Je fais comment avec une clé usb ? y'a un thème automatique qui est associé? Que ce passe t'il si je copie ces dossiers?
Pour les points de montages, je fais comment ?
Si le chemin thématique est par Set, (non ordonné), ça devient compliqué, si c'est ordonnée ça revient a une arborescence indexée donc intérêt très limité, de plus pour les droits d'accès, on gère ça comment?
Bref, pour le moment tu présentes juste une belle fonctionnalité qui peut être gérée par surcouche, on demande juste comment on fait, en pratique, comment ça marche en natif.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par groumly . Évalué à 3.
La question c’est surtout qu’est ce que ça fait, pas si c’est possible.
Si au final, 98% des fichiers du filesystem (pas forcément loin de la réalité, y’a une énorme quantité de fichier systèmes ou applicatifs dont personne n’a rien a faire) on tous un tag correspondant à leur fully qualified path, c’est un peu admettre que le système de tag est un échec, d’une part, et on en droit de se poser la question de savoir si ça en vaut la peine.
D’autre part, ajouter des milliers de tags « systèmes », ça a un coup sur le système d’indexage, et un gros coup sur l’ux, parce que maintenant faut les cacher ces tags. Sauf quand tu les cherche. T’as aussi des problèmes plus fondamentaux. Un path est garanti d’avoir un seul fichier au plus au bout, un tag pas du tout. C’est un peu une recette pour un désastre pour le système si je décide de tagger un fichier /bin/sudo, ou autre joie du style.
Je suis sur que tu peux trouver une approche ou tu peux reconstruire une arborescence à partir de tag, mais c’est à peu près aussi malin que d’essayer de reproduire un système de tags à partir de lien symboliques, comme c’est parfois suggéré.
On en revient à la question de « quel problème t’essayes de résoudre exactement? », et mon petit doigt me dit que la réponse est « tagger quelques dizaines à centaines de fichier utilisateurs, créés en session interactive ». Auquel cas, l’approche d’Apple marche un peu mieux à une fraction du coût.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 2.
Je pense qu’il y a un problème de compréhension de ce que je propose.
Affecter une chemin thématique à un fichier n’est pas plus difficile que d’affecter un chemin physique.
Une idée (très) simple pour simplifier la gestion du chemin thématique serait de convenir de trier les thèmes par ordre alphabétique pour obtenir le chemin « ordonné ».
Si je reprends l’exemple du fichier toto :
- chemin physique : /dossiera/dossierb/toto
- chemin thématique : :thèmea:thèmeb:toto
La (très) très grande différence ente les deux systèmes est qu’en navigation thématique, je peux retrouver le fichier en passant par thèmea OU thèmeb, alors que dans le premier cas, si je ne sais pas qu’il faut commencer par dossiera, je ne trouverai JAMAIS le fichier.
Exemple concret : il y a encore beaucoup de documentation rangées « à la Windows » dans ma boite. Par exemple, les dossiers d’architectures sont rangés par sujets, MAIS classés par année (ça n’est pas la première fois que je rencontre ce !!?,&@« principe). Résultat : à part ceux qui ont participé au projet, un nouvel arrivant NE PEUT PAS retrouver un dossier d’architecture sauf à se coltiner une ribambelle de pan d’arborescence pour rien (cas d’école sur un sujet récent - 2023 : ah non ; 2022 : ah non. Tu demande à un collègue : « l’étude a été faite en 2017, donc il est rangé dans 2017).
Ce que j’essaye de faire comprendre ici, c’est qu’un « bon » rangement se mesure non pas à l’aulne de celui qui range, mais à la facilité avec laquelle n’importe qui PEUT RETROUVER un fichier.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Vlobulle . Évalué à 2.
Toutes les structures ont exactement le même "problème". La totalité s'en sort en "demandant à un collègue où est le projet" ou en faisant des raccourcis. A moins que ton job soit littéralement de passer son temps à chercher des projets, le coût de maintenir un rangement multi-indexé des fichiers dépasse largement le temps passé à chercher un projet la première fois qu'on se met dessus.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par flan (site web personnel) . Évalué à 3.
En fait, tu veux utiliser macOS, qui permet déjà de créer des « dossiers intelligents » : des dossiers contenant tous les fichiers correspondant à des critères définis. Les étiquettes (couleurs visibles dans le Finder), les mots-clefs associés, et plus généralement n'importe quelle méta-donnée, peuvent être utilisés pour choisir les fichiers apparaissant dans ce dossier.
Tu peux faire une simple recherche classique sur tous ces critères (« type de fichier est pdf et contenu contient Paris et le contenu contient projet »), et si tu penses que c'est une recherche récurrente, tu l'enregistres pour qu'elle apparaissent comme dossier.
C'est bien plus puissant qu'un bête système d'étiquette qui ne marchera jamais car bien trop complexe à mettre en œuvre (il faut se souvenir de bien mettre la même étiquette à chaque fois, et non un synonyme, sans compter qu'il faut mettre toutes les étiquettes nécessaires à chaque fichier).
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par groumly . Évalué à 2.
Je lui ait déjà suggéré ça 2 fois, mais non, il a une solution, reste plus qu’à trouver le problème.
Qu’importe que MS, Apple et un certain nombre de projets libres aient tous atteint la même conclusion (système de fichier traditionnel qui nourrit un index) après avoir bossé dessus pendant quelque années.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 1. Dernière modification le 18 février 2024 à 17:27.
C’est vrai que pour les chemins physiques, « légen » rangent leurs photos une fois dans le dossier photos, puis phautos, puis photaus, puis photeaux. Fodirkiçonkonlégen…
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par flan (site web personnel) . Évalué à 2.
Je n'ai pas de stats, et je serais intéressé par en avoir, mais je pense que la plupart se contentent maintenant de les laisser sur leur téléphone, et éventuellement de les perdre si le téléphone est perdu ou cassé.
Pour ça, iCloud est très pratique. Pour une somme modique, le quidam moyen peut être relativement bien protégé : mots de passe forts et différents sur chaque site, VPN, sauvegarde très facile des photos et des contacts voire du téléphone complet, localisation en cas de vol ou de perte, utilisation d'adresses courriel uniques… Je ne connais pas les équivalents chez les autres fournisseurs, mais c'est sûrement la même chose.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Vlobulle . Évalué à 3.
Ce n'est pas pour rien qu'aucun outil grand public n'est construit sur la base de tags.
L'outil Google Drive a longtemps fonctionné en utilisant des hiérarchies de tags en lieu et place d'une arborescence unique - la visualisation était sous forme de répertoires, mais où les chemins d'accès n'étaient pas forcément unique pour un fichier.
Tu pouvais naturellement avoir un répertoire placé à la fois dans "\2023\Projet Fondue" et dans "\Projets Important\Projet Fondue". C'était pratique pour ranger dans tous les sens sans avoir à répondre à la question philosophique, "est-ce que le projet fondue est avant tout un projet important ou un projet de l'année 2023 ?". Par contre, c'était accompagné de side-effects particulièrement confusants : si je déplace pour archiver ou que je supprime l'un des deux répertoires, il se passe quoi ? Ne parlons pas des droits….
La fonctionnalité a été petit à petit déphasée, jusqu'à être complètement supprimée et remplacée par une vraie arborescence unique (et le remplacement forcé de toutes les instances de Projet Fondue par des raccourcis vers une des instances).
Et un système de tags a été rajouté à nouveau par dessus, mais fortement limité (5 tags par fichiers maximum).
Ce n'était pas forcément très bien implémenté pour l'utilisateur moyen, mais surtout, personne n'en avait besoin. Une arborescence unique répond aux besoins de la quasi-totalité des utilisateurs, et l'univers entier s'accommode de ne pas avoir de réponse symétrique à la question d'où placer le projet fondue : les outils ne sont que des outils, pas un objectif en tant que tel.
Dans le même genre, Windows ne propose aucun moyen "user friendly" de faire des hard link entre fichiers. C'est pas un hasard.
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 2. Dernière modification le 15 février 2024 à 11:33.
ah ? J'ai toujours trouvé la façon de faire des vrais liens sous windows assez simple :) (et nettement mieux que les raccourcis)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Psychofox (Mastodon) . Évalué à 4.
Sortie de boite la dernière fois que j'avais vérifié ce n'était possible qu'avec mklink, pas dans l'explorateur de fichier. Ça n'a jamais été destiné à l'utilisateur final.
Il existe une extension qui ajoute la fonctionnalité cela-dit:
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 4.
c'était de l'humour enfin pas que,
mklink n'est pas plus compliqué que ln, et je trouve le terme "user friendly" un peu trop galvaudé, je ne considère pas un truc accessible par interface graphique "user friendly", il faut voir l'usage, et la répétition de l'usage. Ce qui fait que j'ai longtemps préféré linux a windows, c'était la capacité justement d'automatiser les tâches (bash / perl / awk / cut …) avec tout le système pour pouvoir le bricoler aux petits oignons. Les cmd.exe, ou powerShell ne rentraient pas dans les facilité d'usages et étaient particulièrement absons pour pas mal, et s'interfaçait mal avec le reste du système (par exemple comment modifier une variable d'environnement pour les sessions suivante (alors oui y'a windows pause, puis quelques clics, mais c'est pas automatisé.)
Pour pas mal de truc, j'aimais taquiner pbpg pour avoir la ligne magique qui faisait ce que je voulais (gestion des caches disques par exemple).
Enfin bref, mklink, junction, ln, ne sont pas des commandes que le commun des utilisateurs vont utiliser (et surtout comprendre, notamment la suppression), et pour moi la ligne de commande c'est "user friendly", c'est juste qu'on a pas les même attentes.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par Claude SIMON (site web personnel) . Évalué à 4.
À un détail prés. Avec mklink, les paramètres sont
<lien> <source>, alors qu'avec ln, c'est<source> <lien>, ce qui fait qu'avec ln, on peux omettre le second paramètre si le nom du lien est le même que celui de la source, ce qui est très fréquent, enfin en ce qui me concerne, alors qu'avec mklink, il faut systématiquement indiquer les deux paramètres.Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par PhRæD . Évalué à 1.
Je ne sais pourquoi chaque contradicteur s’obstine à croire que je propose d’associer plusieurs chemins à un fichier !
Comme pour un chemin physique, le chemin thématique est unique (avec la simple règle du chemin ordonné).
C’est la navigation vers le fichier qui offre plusieurs possibilités, en permettant de choisir un 1er thème puis un deuxième parmi les restants, etc.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: Confluence, la recherche convergente et le chemin thématique
Posté par fearan . Évalué à 5.
Parce que lorsqu'on parle de système sémantique, il n'y a pas d'ordre; et une photo a la montagne, j'en prends 15, je vais pas chercher un thème différent pour les 15 photos, il y'a aussi le problème d'unicité lorsqu'on met en commun des filesystem, (clé usb, disque nomade, disque réseau…)
Ah oui mais y'a aussi plusieurs partition, donc faut aussi rajouter la partition, et puis je gère comment si quelqu'un veut la renommer ploc, il la copie?
::nomade:utilisateurBidule:plopA:plopB:conf
Ah ouais, mais j'ai 2 clé usb que j'ai appelé nomade, je fais comment?
sauf que ton chemin ordonné va devoir rajouter des éléments comme le nom d'utilisateur, son/ses groupes, sa partition, ses…
Donc un système de fichier arborescent ou chaque dossier est un thème; tu peux déjà le faire; et locate + grep te permet de trouver ce que tu cherches, tu peux développer une IHM qui va se servir de l'indexation des dossier, générer un tag par dossier, et paf c'est fait. Pas besoin de révolutionner un système de fichier.
En plus poussé tu avais feu Nepomuk, maintenant c'est Baloo (ou un truc de ce genre) mais ils se basaient sur les métadonnée des fichiers pour remplir leur base.
Bref demander la réécriture de presque tous les logiciels existant pour aucun ajout de fonctionnalité, pour un truc qui pourrait être implémenté simplement via un explorateur de fichier, je trouve que l'idée est intéressante, mais elle n'est pas mature.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Atlassian rime avec
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 0.
Cardassian bien sur ! Not pas ceux là, ceux là
"Bien que leur apparence puisse faire penser qu'ils sont descendants d'une espèce de reptiles originaire de Cardassia Prime, les Cardassiens, comme les Humains, les Klingons et les Romuliens, sont issus d'une ancienne espèce humanoïde (cf. La Chasse, TNG, saison 6, épisode 20). Ils ont tendance à préférer des environnements chauds et humides difficilement supportables pour des Humains. Modifiés génétiquement, comme tous les humanoïdes, par les Humanoïdes originels, ils n'en gardent pas moins une apparence encore très reptilienne. Celle-ci se caractérise par une peau blanchâtre, deux crêtes osseuses de chaque côté du cou et une excroissance osseuse sur le front ayant vaguement la forme d'une cuillère. Cette caractéristique particulièrement visible leur a valu, lors des guerres du Dominion, le surnom de « faces de cuillère » (Spoonheads). Cette excroissance se retrouve aussi sur le torse ; il s'agirait en effet d'une protection contre l'environnement hostile des marais de l'ancienne Cardassia. Chez les femelles, cette excroissance, tout comme les deux crêtes du cou, est légèrement teintée de bleu. La chevelure des Cardassiens varie en général du brun foncé au noir le plus profond.
Contrairement à la plupart des autres espèces humanoïdes, les Cardassiens sont extrêmement résistants aux effets de l'alcool et des drogues. Enfin, les Cardassiens étant disciplinés dès l'enfance, le trait de caractère mental le plus apparent chez le sujet cardassien moyen est une mémoire photographique et une forte attention aux détails."
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.