Les développeurs d’OnlyOffice ont mis à jour l’application « OnlyOffice pour ownCloud » (déjà présentée sur LinuxFr.org) qui permet actuellement aux utilisateurs d’éditer des documents stockés sur Nextcloud en utilisant les éditeurs de documents en ligne d’OnlyOffice. De plus, le script permettant d’installer Nextcloud intégré avec OnlyOffice Document Server automatiquement en utilisant Docker Compose est maintenant disponible.
OnlyOffice Document Server est une suite bureautique en ligne permettant de travailler avec des documents texte, des classeurs et des présentations en mode collaboratif. Les fonctionnalités principales sont les suivantes :
- prise en charge de tous les formats populaires : DOCX, XLSX, PPTX, TXT, CSV, ODT, ODS, ODP, DOC, XLS, PPT, PPS, EPUB, RTF, HTML, HTM. Toute la liste est disponible ici ;
- jeu d’outils de mise en forme avancé ;
- deux types de coédition : rapide et stricte ;
- commentaires, clavardage intégré ;
- suivi des changements et historique des versions.
OnlyOffice offre une version communautaire distribuée sous les termes de la licence AGPL v3, aussi bien qu’une version enterprise.
L’intégration d’OnlyOffice Document Server à Nextcloud à l’aide de Docker Compose se résume à :
- avoir la dernière version du référentiel docker-onlyoffice-owncloud :
git clone --recursive https://github.com/ONLYOFFICE/docker-onlyoffice-owncloud
cd docker-onlyoffice-owncloud
git submodule update --remote- ouvrir le fichier
docker-compose.ymlet modifier la ligne « image: owncloud:fpm » en entrant nextcloud au lieu de owncloud ; - exécuter Docker Compose :
docker-compose up -d - créer un compte d’administrateur de Nextcloud.
-
revenir dans le dossier du projet et exécuter le script
set_configuration.sh:bash set_configuration.sh actualiser la page Web.
Une action supplémentaire « Open in ONLYOFFICE » sera ajoutée au menu.
Aller plus loin
- Site officiel de d’OnlyOffice (1837 clics)
- Site officiel de Nextcloud (342 clics)
- Dépôt GitHub de l’application (262 clics)
- Tutoriel d’installation pour OnlyOffice Document Server (487 clics)
- 11 choses que l’on peut faire avec OnlyOffice et que l’on ne peut pas faire avec Google Docs (522 clics)
# Docker fourre-tout ?
Posté par Loïc Blot (site web personnel) . Évalué à 9.
Autant je comprends docker dans une démarche industrielle avec des microservices d'entreprises pour la scalabilité d'un service avec une connaissance et la construction de son infra docker (avec un Kubernetes au dessus, bien sûr), autant pour du personnel c'est totalement overkill et non portable sur d'autres OS comme les BSD. Est-il prévu d'avoir une vraie procédure de packaging et configurations des softs ou juste un ensemble de binaires assemblés par magie ?
Veepee & UNIX-Experience
[^] # Re: Docker fourre-tout ?
Posté par Glandos . Évalué à 6.
Pas du tout. Ça télécharge juste un gros paquet de bits depuis https://hub.docker.com/r/onlyoffice/documentserver/ et ça l'exécute. C'est parfaitement transparent.
Bon, oui, je n'aime pas du tout cette manière de distribuer des logiciels, qui va complètement à l'encontre de la compilation reproductible.
Cependant, le travail doit être énorme, et je dois insister sur le fait que je le respecte. Simplement, Docker ne peut pas être une méthode de distribution, simplement une méthode de test.
[^] # Re: Docker fourre-tout ?
Posté par Loïc Blot (site web personnel) . Évalué à 10. Dernière modification le 08 novembre 2017 à 17:56.
Oui le compose utilise des images du hub, mais il reste néanmoins la possibilité de reconstruire l'application et la packager pour les distributions Linux et les BSD. Il y a le même souci avec AWX chez redhat…
C'est devenu la mode de la "portabilité" docker, on fait un bloat, on met des trucs à droite à gauche, on ne met pas à jour les libs car ca coûte cher de faire les upgrades mais paf voila des chocapics.
Veepee & UNIX-Experience
[^] # Re: Docker fourre-tout ?
Posté par cluxter . Évalué à 7.
NB : après relecture de mon post, je sais qu'il apparaît un peu agressif, c'est mon style, je n'attaque personne ici, je suis parfois peu brut de décoffrage, voilà tout ;)
J'ai testé l'installation et la configuration de GitLab en natif sous ArchLinux (avec l'aide du wiki pourtant).
Bilan : 10 jours à me casser la tête pour régler tout ce qu'il fallait (comprendre : pour que ça fonctionne sans bugs), et c'était loin d'être optimisé au niveau des perfs (c'était même franchement mauvais). Quant aux mises-à-jours, c'était (trèèès) loin d'être fiable (en fait c'était pas fiable du tout).
Puis j'ai décidé d'utiliser l'image Docker. 1 journée complète, avec l'optimisation qui va bien pour des performances dignes d'un truc en prod.
Donc lorsque j'ai installé Nextcloud, je n'ai même pas tenté l'installation native, j'ai tout de suite utilisé l'image Docker. Et j'ai été très content de cela il y a 2 semaines lorsque la montée en version de Nextcloud m'a ramené des erreurs. J'ai downgradé en 2 min, j'ai attendu 2 semaines avant de retenter un upgrade, et cette fois c'était bon.
Alors oui, ce n'est pas la voie royale pour empaqueter des logiciels. Mais au-delà des optimisations qui sont déjà toutes faites par l'équipe de dév, c'est bien plus qu'un simple confort pour l'admin que d'avoir la possibilité de mettre en place des plateformes de ce genre très rapidement : c'est la garantie d'avoir tout le temps un truc qui tourne (on se comprend). Sans compter que ça permet de migrer très facilement et rapidement la plateforme d'une machine à une autre lorsqu'il le faut ; avant j'avais un serveur qui n'avait que des appli en natif et ça a été bien long et chiant lorsque j'ai dû passer de cette machine qui était sous Debian à une autre machine qui était sous ArchLinux.
Pour un serveur perso, on peut se permettre d'avoir un truc en carafe pendant quelques jours, passer quelques nuits dessus, dire à Bobonne et à sa bande de potes que dans 3 jours ils pourront de nouveau accéder à leurs contenus.
En revanche lorsqu'on a une boîte à faire tourner (mon cas), c'est une autre paire de manches. Le client se fout totalement de savoir pourquoi votre serveur est down. Passer 3 jours pour remettre sur pieds un simple serveur est impensable, non seulement pour l'indisponibilité du contenu, mais aussi parce que 3 jours de boulot c'est super long quand on développe sa boîte.
Alors vous allez me dire que c'est de ma faute car j'utilise ArchLinux et donc que c'est à moi de tout gérer et que je n'ai qu'à assumer. Oui mais non, car s'il faut faire 10 jours de config pour faire tourner un logiciel (qui n'est même pas encore optimisé), c'est qu'il y a un problème dans la conception de l'appli. Normalement une appli devrait pouvoir être lancée assez rapidement moyennant quelques paramètres ici et là, et ce indépendamment de la distribution. A charge ensuite à l'admin de passer du temps sur le manuel pour l'optimiser selon ses besoins. Mais quand vous vous retrouvez à balancer des hacks dans la config tellement c'est mal conçu (j'ai eu le cas sous GitLab et Nextcloud), non, non et non. C'est là où Docker permet de s'économiser tout un tas de problèmes. Je suis le premier à défendre la philosophie du logiciel libre, mais il arrive un moment où on ne peut plus se permettre de passer du temps à débugguer encore et encore les appli et à soumettre des patchs, on a besoin que ça tourne et Docker permet de faire ça relativement proprement. Ca n'empêche pas de continuer à soumettre des merges requests, ce que je fais, mais en attendant il faut bien faire avancer le schmilblick et payer les factures !
En conclusion : oui, oui et mille fois oui à un empaquetage natif, voire avec Flatpak (ou autre, je suis pas sectaire). Mais non, non et re-non si ça donne un truc crade à l'arrivée. Je préfère une bonne image Docker qui tourne à un truc natif foireux.
PS : je sais que je vais me faire moinsser par un certain nombre d'ayatolas idéalistes du libre qui verront en moi un salaud de patron et probablement un incompétent notoire, reste que l'argent ne me tombe pas du ciel et que j'essaie de trouver le meilleur compromis pour utiliser du libre partout. J'ai cet idéal du libre, mais il faut aussi être réaliste et voir que cet idéal se confronte à des réalités bassement primaires comme : comment je vais payer mon loyer si mon serveur est down et que mon client me paie seulement le mois prochain ? Ca n'est pas remettre en cause le libre que d'agir de la sorte, c'est au contraire essayer d'utiliser coûte que coûte le libre quitte à devoir hacker un peu certains trucs qui peuvent rendre certains puristes malades.
[^] # Re: Docker fourre-tout ?
Posté par oau . Évalué à 6.
Bonjour
apt-get install gitlab marche très bien depuis plus d'un an. Et il me semble bien avoir une version récente : GitLab Community Edition 10.1.2
D'ailleurs mon outils de monitoring me dit que ce matin il y a une mise à jour que je ferais ce soir. Mise à jour d'ailleurs très régulière et je n'ai eu de problème qu'une seule fois lors de la mise à jour du postgresql qui tourne dedans.
Le repo : deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ jessie main
Pour revenir sur docker et étant admin de longue date je vois arriver des tonnes d'application dans des dockers qui ne seront jamais mises à jour et potentiellement pleines de trou. Après les botnets d'IoT on va avoir des botnet d'image docker …
Juste mon opinion :)
bien à vous.
oau
[^] # Re: Docker fourre-tout ?
Posté par Yves (site web personnel) . Évalué à 1.
Je partage vos avis concernant la sur-utilisation de Docker hors entreprise :-(
Une remarque toutefois : Docker améliore la reproductibilité, et non l’inverse ! Et le Dockerfile agit même comme une sorte de documentation. Tu peux remonter de layer en layer et refaire tout pareil (sauf si le layer de base est puisé dans une rolling-distro, je suppose…)
[^] # Re: Docker fourre-tout ?
Posté par damaki . Évalué à 5.
Ça a l'air d'être documenté là bas.
Et sinon +1 contre docker dans le cadre de petites prods. J’abhorre le concept d'utiliser une vm (vous pouvez appeler ça un container, si ça vous chante) non signée et créée par de parfaits inconnus, sur ma prod ou même dans ma machine de test, mais en plus devoir me fader le téléchargement de centaines de mégas sur ma connexion pourrave, juste pour tester, non merci.
[^] # Re: Docker fourre-tout ? retour d'expérience sur la mise à dispo d'images docker
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
C'est succint, mais a priori ça permet de faire le boulot si on ne veut pas de docker.
En fait il y a de plus en plus de gens qui testent et jettent un logiciel. Donc tu es d'une manière ou d'une autre obligé de proposer un moyen de tester/déployer facilement si tu veux acquérir des utilisateurs. Que ce soit la bonne méthode ou une mauvaise méthode n'est pas la question ici - c'est juste qu'il faut un moyen simple pour permettre à l'utilisateur de tester sans effort. Un bon moyen serait de proposer des paquets pour chaque distribution, mais c'est un travail long et moins multi-plateforme que docker, surtout si ton système nécessite des configurations un peu avancées.
Sur tracim un des gros chantiers qu'on a mis en branle ses derniers mois, c'est la génération automatique d'images docker fonctionnelles. L'objectif est double : un workflow d'intégration continue et de tests automatisés "virtualisés" (en gros on teste tout sur un système vierge et jetable/jeté), et la fourniture d'une image docker "clé en main" pour des personnes qui souhaitent, soit tester tracim, soit l'utiliser sans monter en compétence techniquement.
Ca n'empêche qu'on a une procédure détaillée d'installation qui cible les adminsys en particulier et plus généralement les personnes qui veulent maîtriser ce qu'elles déploient.
L'idéal serait de proposer des paquets debian, rpm… mais c'est encore un travail supplémentaire.
Au passage, concernant les centaines de Mo téléchargés à travers une image docker : en compilant, ça n'est pas dit que tu ne tire pas "plus de Mo". Par exemple une image docker de test de tracim fait +/- 2,1Go avant nettoyage car on embarque tout ce qu'il faut pour compiler les dépendances, déclencher la fureur avec node_js, etc pour construire quelques petits morceaux d'interface. La vraie solution optimisée, c'est ni docker ni de compiler à partir des sources, mais bien de packager pour l'os.
[^] # Re: Docker fourre-tout ?
Posté par Yves (site web personnel) . Évalué à 2.
Ah non, une VM et un conteneur, c’est très différent !
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . Évalué à 7. Dernière modification le 08 novembre 2017 à 18:51.
Oui à la base c'est à ça que ça sert… cependant force est de constater que docker a un certain succès comme système de distribution ad-hoc.
J'y vois plusieurs raisons:
La plupart des systèmes de paquet sont assez compliqués, et même Ubuntu par exemple qui s'est donné la peine de réduire énormément la complexité a toujours un système hyper complexe De mon côté, auteur de logiciel, j'ai mon code source, typiquement dans un dépôt Git, une clef PGP pour signer mon paquet et un serveur FTP où télécharger (ici upload) mon paquet source, et pourtant je dois traficoter avec 4-5 outils qui sont souvent des empilements d'autres outils… bref, y'a rien de moins marrant que de construire ses paquets.
En regard, docker est assez simple et se prête bien aux techniques d'intégration continue Un Dockerfile est essentiellement une suite de commandes shell, qui en plus bénéficie d'un système de cache.
Les dépendances utilisées peuvent provenir de bien des sources différentes. Le gestionnaire de paquet d'une distribution n'est qu'un moyen comme un autre d'installer des logiciels – c'est souvent le plus puissant mais aussi le plus coûteux en terme de préparation, dès lors que quelque chose est à préparer. Les autres méthodes sont bien-sûr les tarball, mais aussi les système de paquets spécifiques aux langages ou à une communauté (par exemple npm, yarn, opam, quicklisp, gem, pip, composer pour les langages, Emacs a une fonction spéciale pour installer des packages elisp, et il me semble que certains gros logiciels comme sage ont leur propre système de distribution pour des extensions, mais je peux me tromper). Comme le Dockerfile est essentiellement un shell script, cela permet d'utiliser toutes les dépendances qu'on veut sans s'embêter à préparer des paquets pour les logiciels manquants pour toutes les distributions qu'on souhaite toucher.
Pour des logiciels d'une telle complexité, l'homogénéité des déploiements facilite la maintenance. Pour l'équipe qui développe, le nom de l'image utilisée contient en elle-même toutes les informations de version nécessaires pour essayer de reproduire un bug signalé, par exemple. Il y a régulièrement eu des initiatives pour distribuer les logiciels de cette manière (sur PC-BSD p.ex., il me semble que Ubuntu ou Cent-OS avait aussi introduit une forme de paquet “blob” il y a quelques années, sans que je sache ce qu'ils sont devenus, ou encore les “App bundle” de Mac OS-X, ou les applications Windows pour quitter le monde du libre).
Probablement pour à peu près les mêmes raisons, en 2001, lorsque Open Office est sorti il était distribué soit en source soit en binaires précompilés mais pas de véritables paquets. Lien Wayback Machine
[^] # Re: Docker fourre-tout ?
Posté par Adrien . Évalué à 5.
Ton dernier exemple est intéressant. Aujourd'hui j'aurais tendance à penser que la grande majorité des utilisateurs passent par les dépôts de leur distrib pour utiliser LibreOffice… Ce qui montrerait que les méthodes l'installation « à la rache » des développeurs ne sont pas vraiment plébicités par les utilisateurs, qui préfèrent le système de paquet… C'est à creuser.
Dernier point : Le packaging est compliqué surtout lorsque que le logiciel est question est construit avec les pieds, ou qu'on veut respecter des normes strictes, par exemple celle de Debian, qui sont là pour de bonnes raisons !
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . Évalué à 4.
Ça montre aussi que la méthode “à l'arrache” n'est pas nouvelle et que c'est toujours mieux que de ne pas faire de paquet du tout.
Huuum, je ne suis pas sûr: par exemple bsdowl respecte tout ce qu'il peut respecter: il a son fichier
./configurequi comprend toutes les options--prefixetc. pour configurer les chemins d'installation… etc. La procédure d'installation estEt le paquetage Debian https://github.com/michipili/bsdowl/tree/debian/debian m'a coûté plusieurs heures de recherche dans plusieurs documents (apparemment la documentation officielle n'est pas à jour et tout le monde écrit sa propre documentation simplifiée…) Les courtes notes que j'en ai tiré pour mes propres besoins sont quand-même plus longues que les instructions pour MacPorts alors qu'elles sont moins générale.
[^] # Re: Docker fourre-tout ?
Posté par Adrien . Évalué à 2.
Je suis tout à fait d'accord pour dire que bien des choses pourraient être améliorée dans le packaging Debian, et que ça pourrait être plus simple et accessible.
Si j'ai bien compris ton exemple, tu as un coût assez important à la création du paquet, mais les mises à jour sont relativement aisées.
[^] # Re: Docker fourre-tout ?
Posté par Michaël (site web personnel) . Évalué à 3. Dernière modification le 09 novembre 2017 à 09:58.
Ma stratégie actuelle est plutôt de ne pas faire de mise à jour. Dans l'état actuel des chose écrire des paquets pour Debian (c'est probablement le cas pour beaucoup de distributions) est une compétence à cultiver, et le processus complet est largement trop complexe pour l'utilisateur occasionnel du système. Il y a trop d'outils avec lesquels il faut interagir (pour mettre à jour le fichier ChangeLog, pour tester le paquetage, pour créer le paquet proprement dit, pour l'uploader quelque part) alors qu'en fait de moins point de vue il s'agit d'une seule opération. Ce qui est particulièrement pénible est le lien entre le ChangeLog et le nom du paquet… peut-être que la bonne façon de travailler m'échappe, mais en gros il faut avoir une branche par distribution où on veut envoyer ce paquet … alors que le programme est absolument portable. Bref: on le fait une fois pour essayer et après on se souvient à quel point c'est pénible et plein de problèmes inutiles et on concentre son énergie sur autre chose.
L'approche de FreeBSD ou MacPorts est, en comparaison, bien plus simple pour le porter.
[^] # Re: Docker fourre-tout ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Les deb/rpm/… c'est génial pour l'utilisateur, mais l'enfer pour les développeurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Docker fourre-tout ?
Posté par madhatter (site web personnel) . Évalué à 6.
C'est génial pour l'adminsys aussi. ;)
There is no spoon...
[^] # Re: Docker fourre-tout ?
Posté par Philippe M (site web personnel) . Évalué à 4.
Depuis plusieurs mois je tests beaucoup de logiciels (ERP, PIM…), au début je me prenais la tête à chercher des paquets (rpm) pour ma plateforme de test mais c'est peine perdue car il faut tenir compte de la version de l'os disponible sur l'infra, la version des logiciels installés, des besoins de chaque appli déjà installé sur la futur plateforme de prod (en cas d'incompatibilités), des dépendances de l'appli à tester, du sens du vent et du cour de la cacahuète en nouvelle Papouasie… Autant se pendre par la paupière droite tout de suite :(
Exemple pour le PIM Akeneo
C'est une appli web dev en php. L'installation est préconisé sur Debian, mince j'ai que du RedHat au boulot. Ca commence mal, mais je continue la lecture de la doc. Classiquement Apache 2.x (facile), Mysql-server (trop fastoche), php 7.1 (oupss), php-fpm (re oupss). La suite ressemble à la course poursuite d'Indiana et la boule géante dans "Les aventuriers de l'arche perdue", surtout ne pas trébucher : Elasticsearch, Java, Nodejs, Yarn… J'en oublie probablement… Celui qui me trouve tout ça en rpm sur Redhat 7.2 je lui fais une… ola. Sur Debian Strech c'est presque plus simple ou en tout cas documenté. Il y a une image Docker dispo mais j'ai pas vraiment réussi à la faire marcher. Du coups je me suis créé un petit dockerfile de base pour une debian, installé, malmené, torturé, fouetté, bisouillé… tout ce que vous voulez en é, sans me prendre la tête avec l'os de base. Maintenant que j'ai validé que c'est l'appli qu'il nous faut j'ai 3 choix possibles :
Pour moi les gestionnaires de paquets sont bien pour la distribution des "programmes systèmes", mais dès qu'on est dans la distribution d'applications plus lourdes et/ou métier je trouve que docker est une bonne solution.
Born to Kill EndUser !
# en libre
Posté par ckiller . Évalué à -1.
et sinon, il y a quoi comme solution libre pour remplacer OnlyOffice ?
ca a causé libreoffice online un temps, mais ca a l'air mort http://www.numerama.com/magazine/32616-libreoffice-online-date.html dommage, quand on voit les googles docs ou 365, le train semble passer sans solution libre.
[^] # Re: en libre
Posté par bentix . Évalué à 5.
Plutôt que de se référer à un article de numerama datant de 2015, il est mieux de prendre les infos à la source, cela n'a pas l'air si mort que cela: https://wiki.documentfoundation.org/Development/LibreOffice_Online
# Quelques informations
Posté par genma (site web personnel) . Évalué à 5.
OnlyOffice : OnlyOffice ne supporte pas nativement le format OpenDocument (format utilisé par la suite LibreOffice), les documents existants aux formats LibreOffice sont convertis (seul le nom est conservé) pour les modifications des fichiers.
Le format OpenDocument n’est utilisable que pour l’export et le téléchargement de documents (les formats proposés étant alors ceux de MS-Office (.docx, .xlsx, .pptx), de LibreOffice (.odt, .ods) et des formats ouverts et interopérables (.pdf, .txt, .csv, .html)).
Sur LibreOfficeOnline, il y a https://wiki.documentfoundation.org/Development/LibreOffice_Online
Collabora On Line reposant sur LOOL qui lui-même utilise le moteur de Libreoffice, et Collabora est également disponible pour Nextcloud. Egalement sous la forme de container.
[^] # Re: Quelques informations
Posté par Yves (site web personnel) . Évalué à 3.
J’ai mis à disposition dans AUR, pour les utilisateurs de ArchLinux, un package Collabora-Online sans Docker ;-)
https://aur.archlinux.org/packages/collabora-online-server-nodocker/
# Transparence et confiance ?
Posté par cpm . Évalué à 4.
Questions :
- Quelles sont les différences entre la version communautaire et la version entreprise ?
- Les différences sont-elles fonctionnelles ?
- Les licences sont-elles différentes ? Quelle est la licence de la version entreprise ?
- Y-a-t-il un lien clair et précis sur le site pour comprendre les différences entre les versions ?
- Quelle est la version (communautaire, entreprise) utilisée pour l'offre Cloud ?
- Pourquoi opposer communauté et entreprise dans le vocabulaire ?!!
Sur le site web, on peut lire :
Comment est-ce possible sachant que ces formats n'ont pas leurs spécifications complètes publiées ?
[^] # Re: Transparence et confiance ?
Posté par genma (site web personnel) . Évalué à 2.
Les réponses sont ici https://fr.wikipedia.org/wiki/Onlyoffice
Version communautaire versus version pro:
- La version SaaS est destinée aux organisations intéressées au service prêt à l'emploi. Les utilisateurs peuvent démarrer rapidement leur portail d'entreprise qui est régulièrement mis à jour par Ascensio System et hébergé par Amazon.
- La version libre et gratuite dont le code est disponible sur SourceForge est destinée à ceux qui veulent télécharger et déployer ONLYOFFICE sur leurs propres serveurs.
ONLYOFFICE est réalisé en ASP.NET et donc utilise des API Microsoft fermées?
[^] # Re: Transparence et confiance ?
Posté par cpm . Évalué à 2.
On pourrait espérer trouver ce genre d'information sur le site officiel. Merci quand même \o/
Hmmm, normalement, impossible de mélanger du code GNU AGPL avec du code privateur. Comment font-ils ?!!
[^] # Re: Transparence et confiance ?
Posté par pasBill pasGates . Évalué à -6.
Tout simplement parce que tu as tout faux. Les specs sont publiées et complètes.
[^] # Re: Transparence et confiance ?
Posté par xcomcmdr . Évalué à 4.
Ce n'est plus un tas de 6000 pages bourré de contradictions, d'incohérences, et d'informations manquantes, et très dépendant de l'implémentation qu'est MS Office ?
Première nouvelle !
https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML#Technical
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Transparence et confiance ?
Posté par pasBill pasGates . Évalué à -6.
Faudra penser à trouver mieux que le FUD de compétiteurs de MS.
Genre je sais pas, tu arrives à nous montrer des éléments spécifiques qui ne sont pas documentés ?
Bonne chance.
[^] # Re: Transparence et confiance ?
Posté par xcomcmdr . Évalué à 2.
La nique du process de certification ISO, l'état des specs, etc… tout ça c'est du FUD.
Bien sûr, tout le monde s'est mis d'accord pour FUDer en même temps.
Ça va la théorie du complot ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Transparence et confiance ?
Posté par pasBill pasGates . Évalué à -2.
Alors Tu me le donnes cet exemple ? Ca doit pas être dur si je t'écoutes.
# STOP TRAQUAGE !
Posté par cpm . Évalué à 6.
Le site web est plein d'appel à des ressources externes qui sont d'autant d'outils indélicats de traquage (voire illégaux sans le consentement préalable du visiteur…) : cloudfront.net, facebook.net, google.com, twing.com, googleapis.com, yandex.ru, ETC.
Question : est-ce que l'utilisation d'OnlyOffice oblige d'accepter ce traquage ? Version cloud ? Version téléchargée ? Version « entreprise » ?
À noter que la plupart de ces ressources externes pourraient être internalisées et que ce point technique ne devrait pas être bloquant pour l'éditeur d'un produit aussi technique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.