Le créateur d'ownCloud, Frank Karlitschek, vient d'annoncer un fork hostile de son projet après avoir claqué la porte de l'entreprise ownCloud il y a un mois. La suite de la dépêche donne des détails sur cette annonce.
 |
▶▶▶ |  |
|---|---|---|
ownCloud est un logiciel permettant de créer et utiliser un service de cloud. Le logiciel peut être installé sur votre propre serveur pour bénéficier de partages et de synchronisation de fichiers, calendriers, contacts, lecteur de musique, etc. Pour ne pas avoir à installer et gérer un serveur ou pour bénéficier de services supplémentaires, une entreprise a été créée en 2011 et propose une version Enterprise.
Le 27 avril 2016, Franck Karlitschek a posté un billet sur son blog qui commence en ces termes :
Recently I had to make one of my hardest decisions so far. Because this has an impact beyond myself I want to share this here: I am leaving ownCloud, Inc. today. But, the journey of ownCloud and Frank is not over!
Puis il explique ses divergences avec sa propre entreprise sur la vision de la communauté, sur le respect des contributeurs bénévoles et sur l'avenir à long terme d'ownCloud. Il faudra ensuite attendre 5 semaines pour qu'il annonce le fork d'ownCloud sous le nom de Nextcloud et la création de la société Nextcloud GmbH pour proposer logiciels et services aux entreprises et grosses organisations.
Que propose donc Nextcloud de différent et de meilleur ?
Pour les contributeurs
- arrêt de l'utilisation d'un contributor license agreement (CLA)
- arrêt de la double licence
- le trademark va être porté par une fondation indépendante
- un développement ouvert à la communauté à la place d'un développement semi-fermé
Pour les utilisateurs
- gestion complète des fonctionnalités calendriers et contacts
- gestion des visioconférences grâce à Spreed.ME, WebRTC, et Spreed WebRTC
- gestion de certaines fonctionnalités aujourd'hui disponibles uniquement dans la version entreprise d'ownCloud
Pour les clients et les partenaires
- Gestion complète des contacts, calendrier et webmail
- Gestion complète de la visio-conférence
- Travail ensemble pour définir la feuille de route
- Nextcloud GmbH est créé pour avoir une vision long terme et pas des bénéfices rapides
Pour les employés
- Nextcloud GmbH cherche la pérennité et non pas une croissance à court terme
- Les actionnaires seront les employés
- Respect de la vie privée et sécurité des données interne et externe
- Travail en équipe et création de lignes directrices pour l'entreprise et d'un code de conduite pour travailler avec la communauté.
Par ailleurs, Nextcloud GmbH s'engage à prendre en charge gratuitement tous les clients actuels owncloud pour simplifier la transition. Nextcloud est annoncé pour juillet prochain.
Aller plus loin
- Journal à l'origine de la dépêche (1118 clics)
- Nextcloud (2518 clics)
- Site de Frank Karlitschek (467 clics)
- Précédente dépêche sur ownCloud (280 clics)
# - pour les distributions
Posté par Xavier Bestel (site web personnel) . Évalué à 4.
Toujours aucune coopération en vue. Du coup pas de paquet Nextcloud maintenu correctement, avec des scripts d'upgrade qui ne cassent pas tout.
https://help.nextcloud.com/t/will-nextcloud-be-inviting-to-distribution-packages/89
[^] # Re: - pour les distributions
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 07 juin 2016 à 14:23.
ton lien indique justement que le problème n'est pas que chez ownCloud/nextCloud mais qu'il y a un gros problème de dispersion chez les distros (tiens, il n'y a pas que moi qui le dit?).
Donc contrairement à ce que ton commentaire sous-entend, le problème est bien plus général (comment les distributions peuvent faire pour coopérer avec l'upstream sans le surcharger à coup de truc spécifique par distribution; comment pouvoir mettre à jour une application à la dernière version du moment et pas à celle figée il y a 6 mois avec une faille de sécurité déjà corrigée depuis la version il y a 5 mois?) que nextCloud/owncloud. C'est particulièrement important pour les applis qui bougent très vite (rien de nouveau : le plus gros problème visible sur le sujet est par exemple Firefox et il me semble que les distributions abandonnent petit à petit l'idée de figer une version précise de Firefox pour des mois ou années, mais tout le monde n'a pas le poids de Firefox pour faire bouger les choses).
Qui sait, un jour les distributions Linux comprendront que pour avoir de la coopération avec l'upstream, il faut déjà qu'elles coopèrent ensemble pour ne pas surcharger l'upstream avec du travail non constructif.
Reste à savoir si il est possible d'avoir un script commun à Debian/Ubuntu/CentOS/Fedora/Arch, et qui le fait (pourquoi ça serait à l'upstream de faire une tâche qu'ils se créent eux-mêmes alors que ça semble bien marcher avec ce que l'upstream fournit dans ses releases à lui?)
Bref, c'est un problème largement plus général que ownCloud/nextCloud, et ça ne se réglera pas en changeant de stratégie open source pour un logiciel particulier car ce n'est pas un problème sur un logiciel particulier, ta critique sur un logiciel particulier rate sa cible.
[^] # Re: - pour les distributions
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
En fait Debian a fait un script d'upgrade, et était prêt à le faire adopter upstream. Mais la philosophie upstream était en gros "pas de paquet dans les distros, tout doit passer par nous", avec des upgrades très hasardeuses et des dépendances pas soignées.
Les paquets de distributions sont toujours plus soignés et mieux intégrés que les paquets upstream (dans le cas d'Owncloud j'ai essayé les 2, il n'y avait pas photo, Owncloud upstream était une catastrophe ambulante), imagine-toi si tu devais récupérer tous les composants de ta distro au petit bonheur sur une foultitude de sites différents.
Pour un peu de lecture dans le cas spécifique de Debian, c'est ici: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816376
[^] # Re: - pour les distributions
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 07 juin 2016 à 14:42.
de ce que je comprend d'un lien de ton premier lien, le soucis est que ce n'est pas générique, donc pas mettable upstream (j'ai mal compris? ça parle plus d'Ubuntu donc on ne parle peut-être pas de la même chose)
Je ne dis pas que ownCloud est parfait (de ce que je lis, ça ne semble pas être la cas), mais un "cas spécifique Debian" est tout autant un problème qu'un script upstream mal foutu : un script d'upgrade ne devrait être spécifique à une distro qu'à la marge (option de config?).
le script fait par Debian est-il transposable sur une Fedora par exemple? Si la réponse est "non", c'est un script tout aussi mauvais que l'upstream "catastrophe ambulante" (mais supporté).
La coopération, c'est dans les deux sens : il faut que celui qui propose le script fasse un script qui ne soit pas que pour lui mais pour l'ensemble des gens, sinon ce n'est pas très utilisable donc normal d'être refusé upstream.
[^] # Re: - pour les distributions
Posté par Xavier Bestel (site web personnel) . Évalué à 7.
Oui le script était fait pour être transposable, le problème est que certaines personnalités d'Owncloud (Jos) sont viscéralement contre laisser les distributions maintenir leur version (lis les échanges).
Et les mêmes personnalités font partie de Nextcloud et n'ont pas l'air d'avoir changé d'avis sur ce point: en gros si tu veux du support long terme tu prends un "contrat d'entreprise", sinon tu es beta-testeur à vie.
[^] # Re: - pour les distributions
Posté par Zenitram (site web personnel) . Évalué à 1.
OK, j'ai sans doute lu trop en diagonale et je n'avais pas compris que le script était générique (je le comprenais très centré sur Debian/Ubuntu).
faut bien gagner sa vie ma bonne dame :).
si c'est les mêmes personnes et les mêmes façons de voir les distros (en opposition même si un mec fait le taf en générique), le fait qu'ils annoncent des super trucs "en direction de la communauté" est bof pas crédible, on se retrouve alors avec de l'open source pour faire joli et pour te vendre une solution aux problèmes qu'on créé soit même à dessein.
La dépêche laissait espérer que le tempérament serait différent, ça refroidit.
[^] # Re: - pour les distributions
Posté par EauFroide . Évalué à 8. Dernière modification le 07 juin 2016 à 15:03.
C'est vrai qu'owncloud c'est le prestashop du cloud: on a l'impression d'être une vache à lait là pour mettre en valeur la version payante.
quelle excuse, heureusement que le noyau linux ne suit pas cette logique si non on serait encore sur windows.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: - pour les distributions
Posté par romu . Évalué à 2.
P'tet que Flatpak peut justement être une solution au problème de dispersion.
[^] # Re: - pour les distributions
Posté par Zenitram (site web personnel) . Évalué à 0.
Flatpak est un n-ième tentative, le problème est que rien n'a changé depuis l'échec des autres tentatives : pas d'accord entre les distros (hop un ubuntu snap!), pas d'engagement clair des distro à faire le nécessaire pour ne pas mettre des bâtons dans les roues.
Aucun problème technique, juste un problème humain, c'est le humains qu'on doit d'abord "fixer" ;-) avant de partir sur la technique.
[^] # Re: - pour les distributions
Posté par Antoine . Évalué à 2.
Ou alors, pour une solution portable sous Linux, OS X et Windows, il y a conda (avec conda-forge pour la construction de paquets et anaconda.org pour leur hébergement).
[^] # Re: - pour les distributions
Posté par Zenitram (site web personnel) . Évalué à -4.
Je n'ai rien compris à tes liens.
un exemple de logiciel instable de cette manière?
PS : on commence la dispersion… Pour remplacer des scripts par distro, on va se taper des scripts par gestionnaire multi-distros, où est le gain?
[^] # Re: - pour les distributions
Posté par Antoine . Évalué à 2.
Tu demandes probablement un exemple de logiciel installable ;-)
Il y a la distribution Anaconda, qui fournit tout un écosystème d'outils pour le calcul et le développement scientifique.
Il y a aussi tous les paquets fournis par la communauté sur anaconda.org. Les cas d'usage tournent en général autour du calcul scientifique (bibliothèques, outils, interfaces graphiques).
J'admets que la présentation ne permet pas de se faire une idée facilement :-/
Le gain ici est d'avoir une interface de construction et d'installation de paquets unique quel que le soit le système d'exploitation.
condaa également pour avantage de permettre des installations utilisateur (donc sans accès admin et sans toucher au système) et une gestion d'environnements (ce qui permet de régler le problème des conflits de version et de dépendances en utilisant des environnements séparés).[^] # Re: - pour les distributions
Posté par gasche . Évalué à 10.
Zenitram, je pense que tout le monde est d'accord pour dire que ce n'est pas super pour l'upstream d'avoir à packager pour toutes les distros. Mais il faut bien comprendre que le coût que ça a et les bénéfices qui y sont associé peuvent rendre cette possibilité plus ou moins importante selon les projets.
Si je développe un jeu vidéo indie solo, je veux pouvoir distribuer vite mon logiciel aux utilisateurs, et je vais peut-être faire des updates mais pas forcément souvent (et rarement ou jamais des mises à jour de sécurité). Du coup les distros sont très limitantes et un format tout-bundlé est attirant.
Par contre quand je distribute des services webs qui vont tourner en permanence sur des serveurs et sont sensibles question sécurité (données personnelles de mes utilisateurs, etc.), là la plus-value associée au coût du packaging distro peut devenir vachement plus intéressante. Mes utilisateurs ils veulent pouvoir utiliser leurs outils de sysadmin habituels, leurs canaux habituels quand la n-ième faille dans OpenSSL est découverte, et surtout si chaque fournisseur de logiciel serveur refusait de packager ce serait l'enfer sur terre pour ces utilisateurs.
Du coup je pense que ton commentaire un peu tout-préparé sur la lourdeur des processus de packaging est moins pertinent ici. Pour OwnCloud, pouvoir utiliser les outils de sa distro est vraiment important pour certaines personnes, pour des raisons qu'on ne peut pas écarter en disant juste "les distros font chier". On peut vouloir améliorer leur processus, essayer faciliter le packaging, les laisser s'en occuper seules et juste faire le minimum pour leur faciliter la vie, râler sur le nombre de distros; mais il y a un vrai besoin qui fait sens dans ce cas.
[^] # Re: - pour les distributions
Posté par Vincent Bernat (site web personnel) . Évalué à 10.
La discussion est assez symptomatique. La personne à l'origine de la discussion explique bien qu'il n'a pas le temps d'upgrader tous les six mois et donc qu'il utilise des paquets Debian. On lui répond en gros qu'il faut payer pour avoir une version maintenue à long terme.
Je vois ça comme de l'hypocrisie : ce besoin d'une version stable est publiquement considérée comme une hérésie alors qu'il y a manifestement de telles versions maintenues pour des clients qui paient (c'est donc un marché intéressant pour OwnCloud/NextCloud).
[^] # Re: - pour les distributions
Posté par Loïc Blot (site web personnel) . Évalué à 2.
Concernant FreeBSD je l'ai porté hier (ca m'a pris un petit quart d'heure) et il est disponible depuis cette nuit dans l'arbre de ports et certainement bientôt dans les packages:
Veepee & UNIX-Experience
# Frank Karlitschek
Posté par j (site web personnel) . Évalué à 2.
1er lien (Frank Karlitschek) à remplacer par https://en.wikipedia.org/wiki/Frank_Karlitschek
[^] # Re: Frank Karlitschek
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Corrigé, merci.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# et les app'
Posté par jemore . Évalué à 1.
OwnCloud fournissait, en plus de la partie serveur et de leur version "Saas", les clients (Linux, Windows, OSX, Android…) . Que vont elles devenir ?
Si le serveur nextcloud respecte le protocole WebDAV, ces app' devraient toujours fonctionner, mais elles peuvent aussi être "forkées" par ce nouveau projet, et peuvent évoluer en s'améliorant (je pense surtout à la version Android, qui n'est pas franchement folichonne…)
[^] # Re: et les app'
Posté par iGor (site web personnel) . Évalué à 1.
Quelques éléments de réponse sur les forums de nextcloud : Desktop & Mobile Apps
D'ailleurs, de manière générale, help.nextcloud n'est pas d'une consultation inutile.
# Migration
Posté par Adminrezo (site web personnel) . Évalué à 1.
J'ai lu quelque part que la migration de Owncloud vers Nextcloud serait facilitée, est-ce que quelqu'un a des infos sur le sujet ou c'est encore trop tôt ?
[^] # Re: Migration
Posté par EauFroide . Évalué à 1.
C'est aussi le moment pour ceux qui gèrent de CozyCloud de faire une dépêche pour comparer toutes les fonctionnalités de CozyCloud et ses spécificités avec owncloud/nextcloud car on va se retrouver face a un dilemme (conserver owncloud ou passer à nextcloud avec des risques sur la pérennité/stabilité sur le moyen terme pour les deux cas) et se serait bien de se donner toutes les cartes (puis ça fait des users potentiels en plus pour cozy)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Migration
Posté par genma (site web personnel) . Évalué à 5.
La différence au niveau technique c'est PHP + MySQL pour Owncloud vs Node.js + Couchdb pour CozyCloud.
J'avais commencé une comparaison du point de vue graphique/interface. Ce sont des captures d'écran comparatives disponibles ici https://github.com/genma/CozyCloud_vs_Owncloud
Il faudrait que je complète le document. Ca donne une idée pour le design/ergonomie ainsi que les fonctionnalités existantes.
Si des personnes veulent aider/participer/contribuer à compléter le document, elles sont les bienvenues.
[^] # Re: Migration
Posté par xavier Granveaux . Évalué à 8.
Owncloud est multi user, et cosy mono user… Et ça, au delà des considérations techniques, c'est déjà une différence de fond qui en refroidira plus d'un.
En tout cas moi déjà : j'avais été séduit par le produit cosy, mais l'impossibilité de gérer des utilisateurs a laissé le produit sur la touche, dommage !
[^] # Re: Migration
Posté par Skilgannon . Évalué à 2. Dernière modification le 07 juin 2016 à 16:52.
heu … au vue de ton pdf, je m'aperçois que je me trompe depuis quelque temps : je sais pas pourquoi mais j'ai toujours pensé que cozycloud était plus orienté mono utilisateur et owncloud multi-utilisateur …
D'autre part, je me trompe peut être mais n'aurait il pas été judicieux de comparé Yunohost et CozyCloud ?
Enfin bref merci ^
Edit,suite au commentaire de xavier Granveaux :
ha bha m** alors … on peut gérer plusieurs utilisateur dans Cozy ou pas ?
Bon le mieux c'est de tester donc j'installerai Cozy pour voir vraiment ce qu'il en est
[^] # Re: Migration
Posté par Xavier Teyssier (site web personnel) . Évalué à 7.
Non, non. Cozy, c'est pour un seul et unique utilisateur.
Extrait de la FAQ :
Puis-je créer des comptes pour ma famille et mes amis sur mon instance Cozy ?
Cozy est un cloud personnel, et il ne gère pas plusieurs utilisateurs. Cela nous permet d'assurer la sécurité de vos données et de simplifier considérablement l'administration serveur.
[^] # Re: Migration
Posté par reynum (site web personnel) . Évalué à 4.
Ça faisait un bail que je n'étais pas allé voir cozy et ça a bien bougé.
Par contre y a t il un lien direct dans l'application file pour partager un fichier/dossier avec quelqu'un ?
Est ce qu'on a un accès direct via webdav au système de fichier ?
Est ce que le webmail fonctionne avec free ?
Est ce que les protocoles CardDav et CalDav (plugin sync) fonctionnent bien ?
Si tout ça est ok alors Cozy a plus de fonctionnalité intéressante pour moi que mon viel Owncloud 7 (Debian Jessie)
kentoc'h mervel eget bezan saotred
[^] # Re: Migration
Posté par EauFroide . Évalué à 5.
J'avais aussi entendu parler que (sur cozy) les fichiers sont stockés dans une base de données plus tôt que dans le file system, se qui est un énorme défaut de mon point de vue (ça bloque l'interopérabilité avec d'autres logiciels genre transmission, retroshare, VLC, clementine, etc). Faudrait voir si c'est toujours d'actualité :P
Quid aussi du streaming?
J'ai fais un tuto pour upgrader owncloud, si tu veux voici le lien ;) rédigé lors d'un passage de owncloud 8 à owncloud 9
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Migration
Posté par reynum (site web personnel) . Évalué à 6.
OMG mais c'est horrible ce que vous dîtes là !
Si c'est vraiment le cas je ne suis pas prêt de passer à Cozy !
kentoc'h mervel eget bezan saotred
[^] # Re: Migration
Posté par EauFroide . Évalué à 3.
Source : https://docs.cozy.io/fr/host/manage.html (section "augmenter l'espace disque")
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Migration
Posté par reynum (site web personnel) . Évalué à 2.
Et bien Cozy n'est pas pour moi :-)
Pour l'instant à part un webmail fonctionnel Owncloud me convient je verrais quand Nextcloud sera packagé et disponible dans les backport de Jessie (si ça arrive un jour).
kentoc'h mervel eget bezan saotred
[^] # Re: Migration
Posté par barmic . Évalué à 4.
Histoire de pouvoir en discuter, tu peux dire ce qui te choque ?
Personnellement le choix de stocker sur disque ou dans une base de données dépend vraiment des cas. Je trouve cool de pouvoir récupérer tout le contenu d'owncloud (quand je m'en servais) grâce à un
rsync. Mais en pro j'ai déjà stocké des fichiers en base (ou dans des choses bizarres comme S3) pour avoir des machines immuables et stateless. Je sais qu'iCloud stocke tout dans une base cassandra.Bref c'est pas aussi clair que ça pour moi :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par reynum (site web personnel) . Évalué à 10.
En fait je suis un utilisateur très régulier de sshfs, webdav et nfs. De plus j'ai une logique très orientée système de fichier, arborescence …
Stocker des fichiers dans des bases ne me choque pas si c'est pour de l'indexation ou de l'archivage, mais dans une optique de cloud qui pour moi représente une notion de disponibilité et flexibilité des données ; ajouter une couche SGDB et donc perdre l'avantage des protocoles standards (sus-cités) en même temps qu'augmenter la charge du serveur et la complexité des logiciels de synchro ne me parait pas pertinent (pour mon usage).
kentoc'h mervel eget bezan saotred
[^] # Re: Migration
Posté par whity . Évalué à 5.
Je pense qu’un argument en faveur de stocker dans couchdb est justement la disponibilité. Mettre en place une réplication au niveau de couchdb est (d’après les promoteurs, perso j’ai jamais essayé) beaucoup plus simple à mettre en place qu’au niveau d’un FS standard.
En fait, il faudrait que quelqu’un développe un pilote FUSE pour accéder à ces fichiers, et tu retrouverais tes petits.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Migration
Posté par barmic . Évalué à 3.
:) pour moi dans une vraie optique cloud, les nœuds de données sont séparés des nœuds de traitements. Tu crée un cluster de ta base de données et autant d'instance du front que tu as besoin. Mais c'est probablement pas le cas d'usage de cozy :)
Accéder manuellement aux fichiers est tout de même une gageure pour ensuite retrouver ces petits en base (on les indexes généralement car faire une requête en base est généralement bien plus rapide que de parcourir le FS).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par Psychofox (Mastodon) . Évalué à 2.
Je pense que tout dépend de ce que tu comptes faire de ton "cloud privé".
Si l'idée c'est de l'autohéberger ça peut être sympa d'avoir des fichiers disponibles dans une arborescence te permettant de les manipuler facilement à la maison dans ton réseau local, de les synchroniser sur une autre machine, etc.
Si l'idée et de l'héberger à distance finalement je pense que s'appuyer sur les système de fichier n'a plus autant d'intérêt.
[^] # Re: Migration
Posté par Firwen (site web personnel) . Évalué à 3.
Personnellement le choix de stocker sur disque ou dans une base de données dépend vraiment des cas. Je trouve cool de pouvoir récupérer tout le contenu d'owncloud (quand je m'en servais) grâce à un rsync.
Stocker un grand nombre de fichiers, ou des fichiers larges, dans une DB relationnelle est une très mauvaises idée, ça n'a jamais été désigné pour ça.
Une DB est orientée pour du stockage de données typées et structurée row ( ou colonne ). Mettre des fichiers dans une DB revient plus ou moins a serializer chaque fichier dans un gros blob binaire géant avant de le mettre lui même dans un fichier. C'est une terrible idée.
Certaines DB comme oracle ou SQL server stocke les fichiers comme fichiers externes, sur disque et les références depuis le namespace de la DB, histoire d’éviter le problème. Mais là ça revient a perdre tous les avantages d'utiliser une DB ….
S3 est un distributed KV store. Stocker des objets de grande taille n'est pas un problème, il a été désigné pour ça. Dropbox mettait l'intégralité de ses fichiers sur amazon S3 jusqu'a recemment.
[^] # Re: Migration
Posté par barmic . Évalué à 3.
Ici il s'agit de couchDB donc pas de relationnel.
Je me sens un peu bête, je ne vois pas vraiment le problème. Il n'y a pas vraiment de sérialisation (ce n'est pas une transformation). Il faut bien sûr que ta base sache gérer correctement des champs de cette taille, mais si la base que tu utilise le propose en quoi c'est aussi terrible que ça ?
C'est indexé comme toutes tes autres données, c'est répliqué de la même façon que le reste de tes données, ça se backup comme le reste de tes données, tu y accède de la même façon que le reste de tes données,…
La manière dont ta base traite tes données ne te concerne pas trop. Qu'est-ce que tu perds dans le fait que la base le stocke à part ?
Un fichier c'est un bloque de données non-structurées, tu as pleins de choses pour gérer ça et il y a une littérature fournie sur la gestion des données non-structurées dans les bases de données (SQL ou pas). Un FS est une solution, mais ce n'est pas forcément celle qui t'arrange le plus. Pour reprendre l'exemple que je connais pour Apple et iCloud, les fonctionnalités de réplications de cassandra sont très pratiques pour eux et le fait de découper le fichier un chunk qui doit donc être agrégé avant d'être rapatrié est vraiment très pratique pour eux (au lieu de télécharger un bloc de 1Gio d'un serveur à un autre, ils récupèrent par exemple 100×10Mio depuis potentiellement 100 serveurs différents).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par Sufflope (site web personnel) . Évalué à 4.
J'en ai plus sous la main là pour vérifier, mais de mémoire, dans les cas où j'ai vu des binaires stockés en BDD (côté techno, du Hibernate + PostgreSQL), c'était quand même plus lourd que le fichier binaire de base.
Plus, c'est chiant quand tu veux voir tes données, si t'as pas prévu une table "binary_data" pour isoler les données des méta-données, tu devras bien faire "select (id, date_created…) from media" et pas select * sinon merci la purge.
C'est chiant pour rapatrier un dump de prod sur l'intégration ou le dev, il va enfler très, très vite. Et généralement on peut imaginer que si t'as tout foutu en base tu es partout parti du principe que les données sont là, donc tu pourras pas forcément "nettoyer" le dump à coup de truncate pour le faire maigrir, sous peine que tout explose dans le code.
Ça oblige à avoir beaucoup de place sur les serveurs de données. Exit la BDD sur SSD, ou alors une baie de SSD hors de prix, ou alors tu devras configurer ta BDD pour qu'elle mette cette table sur des disques moins chers. Donc soit te manger une pénalité de latence pour l'accès aux métadonnées si elles ne sont pas séparées, soit séparer le binaire comme dit plus haut, mais alors un peu réinventer le "je mets mes données ailleurs que dans la BDD".
Alors je parle pas des BDD que je ne connais pas, mais dans un RDBMS, sans être impossible, c'est quand même pas terrible (et même s'il y a des nouveautés dans Postgres ou les autres RDBMS qui rendent ça plus facile, ils ne peuvent qu'aider pour le select * et le stockage séparé sur de l'espace moins cher, pas rendre ton code résilient à l'absence des binaires pour éviter de rappatrier des dumps de 3To en dev).
[^] # Re: Migration
Posté par barmic . Évalué à 3.
Il faut évidement que ce soit bien fait :)
On est globalement d'accord. Les bases relationnelles et toutes les techno qui vont avec (les ORM par exemple) ne savent globalement pas traiter des blob binaires un tout peu gros (c'est utile pour des truc vraiment petits éventuellement comme du une favicon). Les bases en elle-même savent faire des choses là dessus (comme séparer les blobs sur un espace différent et te les présenter comme une même table (comme une vue) et ne charger les blob que si tu l'a vraiment demandé). Mais rien autour ne permet d'en tirer vraiment parti, tu parlais d'hibernate, je ne suis même pas sûr que JDBC puisse correctement gérer ça (ne pas s'attendre à recevoir toute la ligne en une seule fois par exemple).
Je ne connais pas vraiment la problématique SSD ou pas (en terme de prix). Pour parler de ce que je connais avec cassandra, il te demande d'avoir son dossier de stockage sur SSD et il est là pour encaisser des Tio de données.
Bref ça se réfléchis et je n'ai aucune idée de la pertinence de Couch là dessus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par Firwen (site web personnel) . Évalué à 2.
Même si tu considères ça, elles ne sont pas faites pour stocker des gros blobs à tailles variables, sans schemas.
La plupart des scientifiques avec lesquels je travaille ont facilement 2-3 TB sur leur espace personnel sur dropbox… A
Multiplie ça par les ~2000 personnes de mon organisation, et imagine la tête qu'aurait une pauvre DB relationnel derrière ça.
[^] # Re: Migration
Posté par barmic . Évalué à 2.
Ça c'est un problème de scalabilité de ta base, c'est encore autre chose :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Migration
Posté par Firwen (site web personnel) . Évalué à 2.
Je dirai plutot c'est un problème de scalabilité des RDBMS tout court :)
Un RDBMS par design, te donne de fortes garanties en terme de consistante et de faible possibilités en terme de partionning.
Au mieux un RDBMS te donne une réplication maitre-esclave, là ou un KV/Object store pourra aisément te donné une scalabilité linéaire.
Et c'est normal, là où un distributed file system se contente de te donner une consistence par fichier pour les données, et par dossier pour les méta-données, ta DB te donne l'atomicité des transactions par cellule, par ligne et par table.
```
[^] # Re: Migration
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 10 juin 2016 à 16:59.
Oui et c'est le point que j'abordais en disant que tu réinventes un peu un stockage hors de la BDD. Une fois que ton appli est suffisamment souple pour n'avoir besoin des données QUE pour les utiliser réellement (et pas parce que tu voulais savoir le nom du fichier seulement, par exemple, et t'as pas le choix de tout charger) tu as quasi automatiquement la possibilité de ne pas les stocker dans la BDD du tout, et par exemple les stocker sur un autre disque moins cher, du S3 encore moins cher, les foutre dans un CDN…
Tu te fais plus bête que tu n'es, là :-) Je pense quand même que tu as remarqué le léger écart du prix au Go entre HDD et SSD.
J'ai oublié d'y répondre dans mon message initial mais justement si tu colles tes fichier à la bourrin dans une colonne binary y a rien d'indexé du tout ou alors j'ai pas compris.
[^] # Re: Migration
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Oui, on peut partager facilement depuis l'application files.
Non, actuellement les données sont stockées dans CouchDB. On envisage d'avoir un système de stockage modulable où l'administrateur peut choisir où sont stockés les données : dans CouchDB, sur le file system local ou dans un truc comme Open Stack. Pour les auto-hébergés, avoir les fichiers sur le files system serait mieux. Pour les hébergeurs avec beaucoup d'instances Cozy, avoir les fichiers dans un truc comme Open Stack serait plus facile à gérer. Mais bon, nos moyens sont limités et ce n'est pas là que les efforts vont porter dans les prochains mois. On a beaucoup de sujets sur le feu, il faut choisir nos combats.
D'autre part, les fichiers peuvent être répliqués sur un ordinateur personnel sous Linux via le tout nouveau client : https://linuxfr.org/news/synchronisez-vos-fichiers-avec-cozy-desktop.
Il y a un gros travail de refonte en cours du webmail. Il fonctionnait avec free et refonctionnera bientôt. C'est juste que l'on avait beaucoup de petits bugs, un peu de dette technique, un react assez vieux, etc. Et on prend le temps de refaire ça bien pour avoir un webmail que les gens puissent vraiment utiliser au quotidien sans pester sur beaucoup de petits détails.
À ma connaissance, oui.
[^] # Re: Migration
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 09 juin 2016 à 10:41.
On sait ce que cela donne la dette technique quand on essaye de la résorber. Faîtes gaffe ! N'oubliez pas de demander pardon avant le début du sprint.
Bon courage.
[^] # Re: Migration
Posté par Loïc Blot (site web personnel) . Évalué à 2.
Pour la migration j'ai mis quelques notes sur le port FreeBSD de Nextcloud lors de l'installation. La migration se fait en 3 étapes simples (si on ne prend pas en compte des apps installées localement)
Voir https://github.com/freebsd/freebsd-ports/commit/83374afaa2b69c31e8bbe956c89edbe33789e4a0
Nextcloud n'entre pas en conflit avec owncloud sous FreeBSD, chacun son répertoire.
Veepee & UNIX-Experience
# Un autre Cloud
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Pour info, il n'y a pas que OwnCloud/NextCloud et Cozycloud, il y a aussi Pydio : personnellement, je ne l'utilise pas mais j'en ai eu d'excellents échos … et en plus c'est Français !
# tester nextcloud
Posté par zaclys . Évalué à 1.
bonjour,
l'association "la mère Zaclys" qui propose des services owncloud depuis plusieurs année, a monté un serveur démo avec Nextcloud cette semaine, pour tester c'est ici : https://ncdemo.zaclys.com
(avec comme identifiant et mot de passe pour les comptes administrateur et utilisateur : admin / admin et test / test).
Pour en savoir + sur leur service owncloud et nextcloud :
https://cloud.zaclys.com
amicalement,
# Extensions
Posté par Astumed . Évalué à 1.
Faut pas oublier que Own cloud propose des extensions (lecteur multimédia etc) sont-elles compatibles avec Nextcloud
[^] # Re: Extensions
Posté par EauFroide . Évalué à 1.
Tant que les codes de nextcloud et owncloud sont identique: oui.
Quand nexcloud aura divergé d'owncloud, on peut supposer que les extensions ne seront plus compatible se qui sera une lourde perte pour le moins populaire des deux projets.
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Extensions
Posté par EauFroide . Évalué à 1. Dernière modification le 04 septembre 2016 à 15:02.
Doublon a supprimer svp. Faudrait ajouter une regex anti doublon ^
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.