A vrai dire, je ne compte pas vraiment me prémunir contre quoi que ce soit : les personnes hébergeant une instance funkwhale seront responsables de ce qu'elles mettent sur leur instance, et d'avec qui elles le partagent.
D'autres part, il n'y a pas de point central a faire tomber comme avec un grooveshark ou un soudncloud : les instances fonctionnent en autonomie, et même s'il sera bientôt possible de les fédérer, la disparition.de l'une d'entre elle n'affectera pas les autres outre mesure :)
C'est vrai qu'actuellement, les guides de déploiement expliquent uniquement des déploiements avec Nginx comme reverse proxy. J'avoue que je connais très mal apache et que je serai donc bien en peine de contribuer cette documentation.
Ah oui, c'est vrai qu'avec webtorrent il n'y a pas besoin de fédérer les contenus ! Merci pour l'info en tout cas, il faudra que j'aille regarder l'implementation de peertube pour y voir plus clair.
J'avoue que je suis encore très peu compétent sur les protocoles liés à fédération, même si je me documente pas mal en ce moment.
Je te rejoins sur le fait qu'une fédération complète serait idéale. Puisque tu es dedans, peut-être pourras tu répondre a ma question ? Dans peertube, la fédération des vidéos entre instances repose elle également sur ActivityPub ?
Si tu as envie d'essaayer, tu peux rejoindre le salon Matrix, je te fournirai le lien pour t'inscrire sur mon instance :)
Pour les clients subsonic et autres, complètement. J'ai un ticket ouvert la dessus, et cela fait partie des choses que j'ai oublié dans la catégorie "la suite" !
C'est une super idée d'utiliser Seafile pour faire un truc comme ça ! Ça serait encore plus super si l'API Seafile permettait d'intégrer facilement ce genre d'apps (plutôt que de devoir installer carrément un serveur d'appli à côté avec Gunicorn, etc.). Est-ce que tu leur a partagé le projet pour voir leurs retours ?
En l'état, le streaming ne m'a pas l'air possible en utilisant Seafile. Le support des byte-range requests (nécessaire, sauf erreur de ma part, pour du streaming sur HTTP) était présent dans la roadmap pour la version 4, mais la plupart des fonctionnalités listées ne sont pas présentes dans la version qui est effectivement sortie.
Il y a des chances que l'équipe de dev soit en train de bosser dessus, en tout cas, le problème a déjà été soulevé.
Il y a peut-être une possibilité de contourner le problème en attendant, via Fuse. Je dirai que tu peux monter les fichiers de Seafile dans un dossier de ton serveur via Fuse, et servir ce dossier via Apache, pour avoir le support des byte-range requests.
C'est un domaine que je ne maîtrise pas du tout, donc ce que je dis est à prendre avec des pincettes, n'hésitez pas à me corriger.
Merci pour le retour. Je viens de me pencher dessus (bizarrement, il me le faisait pas) et cela provenait d'un problème de session qui doit normalement être réglé (j'ai fait le test via un proxy).
Effectivement, autant pour moi pour le HTTPS c'était une erreur !
J'ai bien lu votre réponse qui apporte les éclaircissements donc j'avais besoin sur le pourquoi du comment vous n'êtes pas parti sur une solution existante type Seafile.
Pour un outil qui propose du chiffrement de bout en bout, je trouve gênant qu'il n'y ait pas d'accès HTTPS par défaut à cette démo.
D'autre part, le fait que le partage soit limité aux utilisateurs inscrits est également problématique pour moi.
A part ça, c'est à mon avis dommage de partir sur une énième solution plutôt que de se greffer à de l'existant (Seafile, par exemple) déjà tout à fait fonctionnel.
Je vous souhaite néanmoins le meilleur pour ce projet.
En théorie oui, mais ce n'est pas toujours pratique pour switcher rapidement entre différentes résolutions.
D'autre part, l'avoir sous forme d'appli web permet de partager facilement un test précis (tel site, sous telles dimensions), plutôt que de dire aux gens de redimensionner leur navigateur.
Enfin, pour des résolutions plus large que ton écran, le redimensionnement manuel est plutôt pénible.
Merci pour le trick Firefox, que je ne connaissais pas !
Concernant la démo inaccessible, le problème vient d'une erreur de ma part dans la config DNS. C'est corrigé mais il faudra probablement un peu de temps avant que ça soit répercuté.
Au cas où, si il y a des personnes qui veulent tester tout de suite, vous pouvez rajouter cette ligne dans votre fichier /etc/hosts :
176.31.98.11 screensizer.eliotberriot.com
Je pense que Seafile peut supporter de tels volumes de fichiers au niveau de la synchronisation, mais que l'interface web aura parfois du mal à s'afficher.
Je constate quelques ralentissements de l'interface web chez moi, lorsque les bibliothèques ont trop de fichiers, même s'il y a eu des améliorations avec la version 3. C'est peut-être dû à mon serveur qui est quand même très peu performant, et qui accueille pas mal d'autres logiciels que Seafile.
Pour la synchronisation proprement dite, je pense que ça peut le faire (mais c'est purement subjectif).
Sauf erreur de ma part, Seafile ne stocke pas les infos sur les fichiers en base de données : je viens de vérifier les trois bases MySQL utilisées par Seafile, regroupées elles doivent peser quelque chose comme 5Mo. Mon instance Seafile compte environ 20Go de données, et plus de 50 000 fichiers.
Point de vue stabilité, Seafile n'a jamais crashé chez moi jusqu'à maintenant (côté serveur). Les seules fois où j'ai du stopper le serveur Seafile, c'est pour les mises à jour. Le client est à mon sens peu gourmand en ressources. Chez moi, c'est 1/2% du CPU quand il tourne en fond, il peut monter à 15 ou 30% mais uniquement lors du téléchargement complet d'une bibliothèque ou d'un merge d'une bibliothèque avec un dossier en local.
Effectivement, je ne suis peut-être pas compétent pour juger, donc tu as peut-être raison, mais il me semble que la synchronisation ne peut pas se faire uniquement côté client : il faut bien interroger le serveur pour savoir quels sont les fichiers à syncrhoniser, etc. OwnCloud côté serveur est entièrement en PHP, donc par rapport à Seafile dont l'outil de synchronisation est en C, je pense qu'il y a malgré tout un net avantage en terme de rapidité pour Seafile sur ce point.
Pour le découpage en blocs, je suis d'accord avec toi, le gain de performances se fait au détriment de la souplesse.
Okay, je viens de faire quelques recherches et il semble que même si la communication client/serveur ne passe par par HTTP/S, il y a bel et bien chiffrement. D'après ce document :
Every seafile desktop client has a unique private key. When a client and a server connect, they will exchange public key and negotiate a session key. The session key is derived from cryptographically secure random number with PDKDF2 algorithm. And it's exchanged between the client and the server with RSA encryption. This session key will be used to encrypt the data transfer with AES-256/CBC algorithm.
Soit, si on traduit en gros :
Chaque client de bureau possède une clé privée unique. Quand un client et un serveur sont connectés, ils échangent leur clé publique et génèrent une clé de session. Cette clé de session est dérivée d'un algorithme de génération de nombre aléatoire. Elle est échangée entre le client et le serveur avec un chiffrement RSA. Cette clé de session est utilisée pour chiffrer les données transmises avec l'algorithme AES-256/CBC.
Personnellement, ça me paraît correct, mais je ne suis pas forcément le plus calé sur la question. D'autres avis ?
Je crois que j'ai dis une bêtise : la synchronisation client serveur ne passe pas par HTTP/S.
J'ai du mal à trouver des informations sur le protocole utilisé. Cette page de documentation explique les interactions entre les différents composants de Seafile, mais pas d'infos sur le protocole proprement dit.
Je vais leur poser la question sur la mailing list et je te dis ça.
Concernant le chiffrement côté client je viens de tester et ça marche comme ça :
Tu crée ta bibliothèque (via le client lourd ou l'interface web) en cochant le case chiffrement et en fournissant un mot de passe
Tu peux accéder à ta bibliothèque via l'interface web en renseignant ton mot de passe. De mémoire, il n'est pas stocké, peut être mis en cache pour une courte durée.
A partir du client local, tu peux télécharger la bibliothèque chiffrée, en renseignant ton mot de passe. Je pense qu'il est gardé en mémoire par le client lourd, qui l'utilise pour chiffrer les informations transmises au serveur. Tes fichiers en local sont accessibles comme n'importe quels autres fichiers, depuis l'explorateur de fichier (pas besoin de passer par le client).
La synchronisation se fait sur HTTP et supporte également HTTPS donc tu peux chiffrer si tu le souhaites. De même, il est possible de créer des bibliothèques chiffrées côté client, par mot de passe. Ce mot de passe n'est pas stocké sur le serveur, ce qui permet de rajouter une couche de protection.
Pour ta deuxième question, il est possible de révoquer l'accès pour les clients. On le voit vaguement sur la capture d'écran de l'interface web, ikl y a un onglet "Clients" à gauche, qui te permet de lister tous les clients connectés à ton compte et de les désactiver.
Je n'ai pas fait de benchmark, mais voici deux points qui jouent à mon avis en faveur de Seafile :
OwnCloud est écrit en PHP, Seafile est écrit principalement en C pour la synchronisation, (et Python/Django pour l'interface web)
OwnCloud stocke les fichiers tels quels, Seafile les découpe en blocs pour optimiser l'espace et le versionning
Mon utilisation personnelle me prouve que Seafile est largement plus rapide qu'OwnCloud. Sur un Kimsufi 2G avec plus de 20Go de fichiers (voir mon commentaire plus haut) la synchronisation est toujours quasiment instantanée.
Donc pour répondre à ta question, je dirais que oui, Seafile est performant.
Une installation pas forcément facile pour tout le monde, car serveur dédié + Django pour l'interface web. Même si c'est pour moi largement compensé par la clarté de la documentation, je comprends que ça puisse être dissuasif par rapport à des logiciels comme OwnCloud, où on balance les fichiers par FTP sur son mutualisé et hop.
Manque (à mon avis) de certaines fonctionnalités aux niveau de l'interface web : barre de recherche (présente uniquement dans la version payante), partage protégé par mot de passe, lien de partage avec date d'expiration, édition de documents ODF en ligne. Ce sont des choses présentes dans OwnCloud qui me manquent parfois. Après, on peut quand même faire sans, pour moi ce n'est pas bloquant
Le fait qu'il y ait une édition gratuite, libre et une édition payante. Je trouve ça dommage, même si je comprends tout à fait les raisons de ce choix.
A côté de ça, pour être honnête, la qualité de ce soft est proprement hallucinante. Certes, Seafile est centré sur les fichiers (pas de calendrier, flux RSS, etc.), mais il le fait bien :
La synchronisation est vraiment hyper-rapide (le client détecte les modifs en quelques secondes et reste peu gourmand en ressources)
jusqu'à maintenant, je n'ai jamais eu de problème de conflits de fichiers (alors que j'en avais tout le temps avec OwnCloud)
Tout est fait pour préserver au maximum les données des utilisateurs (historique, versionning, corbeille avec restauration en un clic).
Les migrations sont presque un moment de plaisir. J'ai migré de la 2.1 à la 3.0 en une demi-heure, parce que je suis lent
Pour info, je fais tourner Seafile depuis environ 9 mois, sur un Kimsufi 2G, avec un total de 20Go de fichiers répartis dans 5 bibliothèques (certaines contiennent plus de 30 000 fichiers). L'interface web peine au premier affichage, lorsque l'arborescence est trop complexe/profonde, mais c'est à peu près tout.
[^] # Re: le désormais défunt Grooveshark.com.
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 2.
A vrai dire, je ne compte pas vraiment me prémunir contre quoi que ce soit : les personnes hébergeant une instance funkwhale seront responsables de ce qu'elles mettent sur leur instance, et d'avec qui elles le partagent.
D'autres part, il n'y a pas de point central a faire tomber comme avec un grooveshark ou un soudncloud : les instances fonctionnent en autonomie, et même s'il sera bientôt possible de les fédérer, la disparition.de l'une d'entre elle n'affectera pas les autres outre mesure :)
[^] # Re: Reverse Apache?
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 2.
Il y a des choses spécifiques au transcoding et à l'authentification sur les fichiers audio qui rendent le le tout plus complexe.
Ça doit probablement pouvoir se simplifier ou s'ecrire différemment sur du apache
[^] # Re: Reverse Apache?
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 2.
C'est vrai qu'actuellement, les guides de déploiement expliquent uniquement des déploiements avec Nginx comme reverse proxy. J'avoue que je connais très mal apache et que je serai donc bien en peine de contribuer cette documentation.
Pour information, la configuration Nginx requise au niveau du reverse proxy se trouve ici: https://code.eliotberriot.com/funkwhale/funkwhale/blob/develop/deploy/nginx.conf
Je serai ravi de reviewer/tester/merger une MR qui traduise cela en directive apache !
[^] # Re: ActivityPub
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 2.
Ah oui, c'est vrai qu'avec webtorrent il n'y a pas besoin de fédérer les contenus ! Merci pour l'info en tout cas, il faudra que j'aille regarder l'implementation de peertube pour y voir plus clair.
[^] # Re: ActivityPub
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 2.
J'avoue que je suis encore très peu compétent sur les protocoles liés à fédération, même si je me documente pas mal en ce moment.
Je te rejoins sur le fait qu'une fédération complète serait idéale. Puisque tu es dedans, peut-être pourras tu répondre a ma question ? Dans peertube, la fédération des vidéos entre instances repose elle également sur ActivityPub ?
[^] # Re: DSub
Posté par obsidien . En réponse au journal Funkwhale, un serveur de musique libre, moderne et convivial, qui recherche des contributeurs. Évalué à 4.
Si tu as envie d'essaayer, tu peux rejoindre le salon Matrix, je te fournirai le lien pour t'inscrire sur mon instance :)
Pour les clients subsonic et autres, complètement. J'ai un ticket ouvert la dessus, et cela fait partie des choses que j'ai oublié dans la catégorie "la suite" !
# Très bonne idée
Posté par obsidien . En réponse à la dépêche Formulaires Seafile (Seafform). Évalué à 6.
C'est une super idée d'utiliser Seafile pour faire un truc comme ça ! Ça serait encore plus super si l'API Seafile permettait d'intégrer facilement ce genre d'apps (plutôt que de devoir installer carrément un serveur d'appli à côté avec Gunicorn, etc.). Est-ce que tu leur a partagé le projet pour voir leurs retours ?
[^] # Re: Streaming de fichier
Posté par obsidien . En réponse à la dépêche Seafile en version 4 : nouvelles fonctionnalités au menu. Évalué à 2.
En l'état, le streaming ne m'a pas l'air possible en utilisant Seafile. Le support des byte-range requests (nécessaire, sauf erreur de ma part, pour du streaming sur HTTP) était présent dans la roadmap pour la version 4, mais la plupart des fonctionnalités listées ne sont pas présentes dans la version qui est effectivement sortie.
Il y a des chances que l'équipe de dev soit en train de bosser dessus, en tout cas, le problème a déjà été soulevé.
Il y a peut-être une possibilité de contourner le problème en attendant, via Fuse. Je dirai que tu peux monter les fichiers de Seafile dans un dossier de ton serveur via Fuse, et servir ce dossier via Apache, pour avoir le support des byte-range requests.
C'est un domaine que je ne maîtrise pas du tout, donc ce que je dis est à prendre avec des pincettes, n'hésitez pas à me corriger.
[^] # Re: Erreur 500 sur l'ajout d'un chrono
Posté par obsidien . En réponse au message Deltime, une appli web de chronomètrage. Évalué à 1.
Merci pour le retour. Je viens de me pencher dessus (bizarrement, il me le faisait pas) et cela provenait d'un problème de session qui doit normalement être réglé (j'ai fait le test via un proxy).
[^] # Re: Quelques remarques
Posté par obsidien . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1. Dernière modification le 24 juin 2014 à 22:50.
Effectivement, autant pour moi pour le HTTPS c'était une erreur !
J'ai bien lu votre réponse qui apporte les éclaircissements donc j'avais besoin sur le pourquoi du comment vous n'êtes pas parti sur une solution existante type Seafile.
# Quelques remarques
Posté par obsidien . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 2.
Pour un outil qui propose du chiffrement de bout en bout, je trouve gênant qu'il n'y ait pas d'accès HTTPS par défaut à cette démo.
D'autre part, le fait que le partage soit limité aux utilisateurs inscrits est également problématique pour moi.
A part ça, c'est à mon avis dommage de partir sur une énième solution plutôt que de se greffer à de l'existant (Seafile, par exemple) déjà tout à fait fonctionnel.
Je vous souhaite néanmoins le meilleur pour ce projet.
[^] # Re: Vue adaptative sous Firefox
Posté par obsidien . En réponse au journal Screen Sizer, une petite appli web pour tester un site sous différentes résolutions d'écran. Évalué à 3.
En théorie oui, mais ce n'est pas toujours pratique pour switcher rapidement entre différentes résolutions.
D'autre part, l'avoir sous forme d'appli web permet de partager facilement un test précis (tel site, sous telles dimensions), plutôt que de dire aux gens de redimensionner leur navigateur.
Enfin, pour des résolutions plus large que ton écran, le redimensionnement manuel est plutôt pénible.
[^] # Re: Vue adaptative sous Firefox
Posté par obsidien . En réponse au journal Screen Sizer, une petite appli web pour tester un site sous différentes résolutions d'écran. Évalué à 1.
Merci pour le trick Firefox, que je ne connaissais pas !
Concernant la démo inaccessible, le problème vient d'une erreur de ma part dans la config DNS. C'est corrigé mais il faudra probablement un peu de temps avant que ça soit répercuté.
Au cas où, si il y a des personnes qui veulent tester tout de suite, vous pouvez rajouter cette ligne dans votre fichier /etc/hosts :
176.31.98.11 screensizer.eliotberriot.com
[^] # Re: Retours d'experience stabilité et volumes
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 2.
Je pense que Seafile peut supporter de tels volumes de fichiers au niveau de la synchronisation, mais que l'interface web aura parfois du mal à s'afficher.
Je constate quelques ralentissements de l'interface web chez moi, lorsque les bibliothèques ont trop de fichiers, même s'il y a eu des améliorations avec la version 3. C'est peut-être dû à mon serveur qui est quand même très peu performant, et qui accueille pas mal d'autres logiciels que Seafile.
Pour la synchronisation proprement dite, je pense que ça peut le faire (mais c'est purement subjectif).
Sauf erreur de ma part, Seafile ne stocke pas les infos sur les fichiers en base de données : je viens de vérifier les trois bases MySQL utilisées par Seafile, regroupées elles doivent peser quelque chose comme 5Mo. Mon instance Seafile compte environ 20Go de données, et plus de 50 000 fichiers.
Point de vue stabilité, Seafile n'a jamais crashé chez moi jusqu'à maintenant (côté serveur). Les seules fois où j'ai du stopper le serveur Seafile, c'est pour les mises à jour. Le client est à mon sens peu gourmand en ressources. Chez moi, c'est 1/2% du CPU quand il tourne en fond, il peut monter à 15 ou 30% mais uniquement lors du téléchargement complet d'une bibliothèque ou d'un merge d'une bibliothèque avec un dossier en local.
[^] # Re: Et niveau perfs ?
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 1.
Effectivement, je ne suis peut-être pas compétent pour juger, donc tu as peut-être raison, mais il me semble que la synchronisation ne peut pas se faire uniquement côté client : il faut bien interroger le serveur pour savoir quels sont les fichiers à syncrhoniser, etc. OwnCloud côté serveur est entièrement en PHP, donc par rapport à Seafile dont l'outil de synchronisation est en C, je pense qu'il y a malgré tout un net avantage en terme de rapidité pour Seafile sur ce point.
Pour le découpage en blocs, je suis d'accord avec toi, le gain de performances se fait au détriment de la souplesse.
[^] # Re: Sécurité
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 5.
Okay, je viens de faire quelques recherches et il semble que même si la communication client/serveur ne passe par par HTTP/S, il y a bel et bien chiffrement. D'après ce document :
Every seafile desktop client has a unique private key. When a client and a server connect, they will exchange public key and negotiate a session key. The session key is derived from cryptographically secure random number with PDKDF2 algorithm. And it's exchanged between the client and the server with RSA encryption. This session key will be used to encrypt the data transfer with AES-256/CBC algorithm.
Soit, si on traduit en gros :
Chaque client de bureau possède une clé privée unique. Quand un client et un serveur sont connectés, ils échangent leur clé publique et génèrent une clé de session. Cette clé de session est dérivée d'un algorithme de génération de nombre aléatoire. Elle est échangée entre le client et le serveur avec un chiffrement RSA. Cette clé de session est utilisée pour chiffrer les données transmises avec l'algorithme AES-256/CBC.
Personnellement, ça me paraît correct, mais je ne suis pas forcément le plus calé sur la question. D'autres avis ?
[^] # Re: Sécurité
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 1.
Je crois que j'ai dis une bêtise : la synchronisation client serveur ne passe pas par HTTP/S.
J'ai du mal à trouver des informations sur le protocole utilisé. Cette page de documentation explique les interactions entre les différents composants de Seafile, mais pas d'infos sur le protocole proprement dit.
Je vais leur poser la question sur la mailing list et je te dis ça.
Concernant le chiffrement côté client je viens de tester et ça marche comme ça :
[^] # Re: Typo
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 2.
Initialement, le contenu était :
Voici quelques unes des nombreuses fonctionnalités de Seafile.
[^] # Re: Upload anonyme
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 2.
Cela existe sur Seafile (lien d'envoi), mais c'est limité à l'envoi de fichiers (pas de création de dossier), et non protégé par mot de passe.
[^] # Re: Typo
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 3.
Exact, merci. Par contre, c'est ma première dépêche et je ne sais pas si je peux l'éditer et comment ?
[^] # Re: Sécurité
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 1.
Pour ta première question :
La synchronisation se fait sur HTTP et supporte également HTTPS donc tu peux chiffrer si tu le souhaites. De même, il est possible de créer des bibliothèques chiffrées côté client, par mot de passe. Ce mot de passe n'est pas stocké sur le serveur, ce qui permet de rajouter une couche de protection.
Pour ta deuxième question, il est possible de révoquer l'accès pour les clients. On le voit vaguement sur la capture d'écran de l'interface web, ikl y a un onglet "Clients" à gauche, qui te permet de lister tous les clients connectés à ton compte et de les désactiver.
[^] # Re: Et niveau perfs ?
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 4.
Je n'ai pas fait de benchmark, mais voici deux points qui jouent à mon avis en faveur de Seafile :
Mon utilisation personnelle me prouve que Seafile est largement plus rapide qu'OwnCloud. Sur un Kimsufi 2G avec plus de 20Go de fichiers (voir mon commentaire plus haut) la synchronisation est toujours quasiment instantanée.
Donc pour répondre à ta question, je dirais que oui, Seafile est performant.
[^] # Re: Re-motivation
Posté par obsidien . En réponse à la dépêche Seafile, un Dropbox-like libre à héberger sort en version 3. Évalué à 10.
Parmi les principaux défauts, je dirais :
A côté de ça, pour être honnête, la qualité de ce soft est proprement hallucinante. Certes, Seafile est centré sur les fichiers (pas de calendrier, flux RSS, etc.), mais il le fait bien :
Pour info, je fais tourner Seafile depuis environ 9 mois, sur un Kimsufi 2G, avec un total de 20Go de fichiers répartis dans 5 bibliothèques (certaines contiennent plus de 30 000 fichiers). L'interface web peine au premier affichage, lorsque l'arborescence est trop complexe/profonde, mais c'est à peu près tout.