Bonjour
J'utilise beaucoup Seafile car cela répond à beaucoup de besoins, mais le projet a l'air de plus en plus mort :
- très peu de commit, et dans lesquels il n'y a pas grand chose (en 2019 c'était déjà pas fameux, mais en 2020 …) ; cf graphs ci-dessous
- github quasiment en mort cérébral : la dernière réponse officielle à un ticket date d'avril
- un ticket demandant si le projet est encore actif est ouvert depuis 7 jours et n'a eu aucun commentaire : https://github.com/haiwen/seafile/issues
Bon en bref ça me semble mal aller, et je cherche donc des alternatives.
Le problème est que je n'en trouve pas ! Seafile permettait de faire beaucoup de choses, et était accessible aux gens normaux, et je n'ai rien trouvé à ce niveau (par exemple Syncthing n'a pas d'historisation). Voici 3 exemples de besoin :
- l'historisation des modifications
- prise en charge de plus de 300k fichiers dans un même dépôt, synchronisation « instantanée » avec client en CLI ; en bref « sans limite » et efficace d'un point de vue réseau
- utilisation de Seafile comme outil de sauvegarde de serveur
Quelqu'un aurait-il des nouvelles du projet ou connaîtrait-il un projet similaire à Seafile ?
PS : je connais NextCloud de nom mais cela a l'air différemment orienté (gestion de document, agenda, etc), que je n'ai pas (encore ?) pris la peine de tester
PPS : commits (en terme de lignes) de 2019 à aujourd'hui
et en 2020 :
# Partage de fichiers
Posté par Julien_J06 . Évalué à 1.
Hello,
En partage de fichiers il y a aussi PYDIO qui ressemble à Seafile
https://pydio.com/fr/home
Julien_c'est_bien (y'a pas que Seb)
[^] # Re: Partage de fichiers
Posté par lem__mel . Évalué à 1.
Intéressant ! Je jetterai un œil un peu plus tard.
Merci pour la piste.
# syncthing ...
Posté par rycks . Évalué à 1.
Hello, essaye de regarder de ce côté : pour ce qui est de synchroniser des très grosses quantités de données ça fait vraiment bien le boulot https://syncthing.net/
eric.linuxfr@sud-ouest.org
[^] # Re: syncthing ...
Posté par lem__mel . Évalué à 1.
Déjà vu mais il ne répond pas par exemple au besoin d'historisation :-(
[^] # Re: syncthing ...
Posté par feth . Évalué à 2.
Si si :)
[^] # Re: syncthing ...
Posté par lem__mel . Évalué à 2.
Nan, Nan :-D
En fait il n'y a que l'historisation de la version N-1.
Comme historisation ça fait pas lourd.
PS : source https://docs.syncthing.net/users/versioning.html
# C'est une excellente question...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
As-tu contacté l'entreprise qui développe Seafile ? Ils font des offres commerciales tout à fait accessibles, même pour un individu ; entrer en contact avec le service commercial est un des meilleurs moyens de savoir si l'outil est encore (activement) développé…
Après c'est une boîte avec une stratégie opencore ; peut-être que (comme beaucoup de boîtes avec ce positionnement) la version opensource est délaissée au profit de la version propriétaire.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: C'est une excellente question...
Posté par lem__mel . Évalué à 2.
C'est une piste. Merci.
[^] # Re: C'est une excellente question...
Posté par lem__mel . Évalué à 3.
Bien vu !
J'ai envoyé avec mon adresse pro le mail suivant :
Et ça a pas loupé : ils sont redevenus immédiatement « actifs » sur le github/forums (enfin actif : c'est surtout des réponses du genre « bug/problème connu, corrigé prochainement ».
Bon au moins je sais qu'ils sont encore vivants et qu'ils cherchent des clients.
[^] # Re: C'est une excellente question...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Bonne nouvelle.
Ils cherchent des clients comme toutes les entreprises et a fortiori celles qui font du libre (spoiler : développer des logiciels libres a le même coût que développer des logiciels propriétaire).
Et s'ils sont réactifs sur des opportunités c'est un bon point ; ou plus exactement : s'ils n'étaient pas réactifs sur ce genre de sollicitation ça serait vraiment inquiétant.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Mort cérébrale, rien que ça...
Posté par matteli . Évalué à 6. Dernière modification le 14 septembre 2020 à 21:18.
La dernière version de seadrive date du 31 juillet dernier.
La version 7.1 de seahub est dans les tuyaux.
Je connais des projets plus mort.
Après le projet est mature, c'est normal que le nombre de commit baisse un peu.
Perso je l'utilise dans mon lycée avec plus de 100 personnes et ça marche impec.
Qu'est-ce qu'il te manque exactement ?
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . Évalué à 3. Dernière modification le 14 septembre 2020 à 22:35.
Il y a des versions et il y a ce qu'il y a dedans.
Tout d'abord Seadrive est un sous projet, ensuite la personne contribuant le plus sur ce projet (récemment) semble être https://github.com/sun20121818 or il ne semble pas appartenir à la société (un freelance ?) ; ce n'est pas clair qui travaille sur quoi : il peut y avoir des gens « Seafile » (chinois), des gens quelconques (chinois), ou des gens d'une autre société (allemande).
Les commits ne sont pas bien lourd et concernent essentiellement de la maintenance ou du « cosmétique ».
J'ai par exemple jeté un œil à une version qui pouvait contenir autre chose que de la correction : la 2.0.2. Voici ce qu'annonce le changelog :
Et si on regarde ce qui est enregistré comme commit à cette version : https://github.com/haiwen/seadrive-gui/commits/v2.0.2
Je n'ai pas su/pu trouver le code permettant le synchro encrypted libraries (celui qui me paraissait nécessiter du travail), par contre j'ai trouvé le support modify cache directory (ici : https://github.com/haiwen/seadrive-gui/commit/b6772f9314a272321ff07e0e8a0acd3e2b96fa3d ) et là encore c'est pas lourd.
/disclaimer : je suis développeur (et de C++ en plus) donc je sais que ce n'est pas le nombre de lignes qui fait le travail, mais là c'est pas lourd.
Bon ensuite je parle du serveur lui-même et pas des « UIs » (Seadrive, Seahub, etc).
En effet, mais je suis sur encore un incident qui va m'imposer de détruire une librairie et la reconstruire (donc en perdant tout l'historique).
Et encore une fois : aucune réponse à des tickets, et je ne suis pas le seul. Ensuite il suffit de jeter un œil aux tickets qui ont été « récemment » fermés (https://github.com/haiwen/seafile/issues?q=is%3Aissue) : soit c'est l'auteur soit il n'y avait peu ou rien de technique.
Regarde le ticket : https://github.com/haiwen/seafile/issues/2366
Le serveur refuse une synchro (il manque un bloc), il ne dit pas quel est le fichier concerné (je pourrais ainsi le supprimer), l'outil de réparation ne fait rien ; situation bloquée.
Pour finir je te remercie de m'avoir pointé les autres projets de Seafile qui montrent un peu d'activité : cela permet de nuancer mon propos.
PS : et puis que Seafile ne réponde pas (ou cloture) un ticket demandant si le projet est mort ( https://github.com/haiwen/seafile/issues/2368 ) ça fait bizarre.
[^] # Re: Mort cérébrale, rien que ça...
Posté par freem . Évalué à 3.
Je me dis, si le projet remplis tous tes besoins, est mature (donc nécessite peu de maintenance), pourquoi ne pas corriger toi-même les bugs sur lesquels tu tombes?
Pas obligé de reverser au repo originel, s'il est mort, non plus.
Je sais que ça implique de s'impliquer, et que ça prend du temps, que souvent on a autre chose à faire, mais si le soft t'es vraiment très utile, ça reste une option.
Accessoirement, je vois qu'il y a pas mal de pull requests ouvertes (9, dont 4 de cette année, et plein d'autres fermées).
Parmi les commits que je lis, il y a notamment des correctifs de memory leaks, pas vraiment le genre de trucs qu'il est aisé de trouver par accident, donc, je dirais qu'il reste des gens qui le font vivre.
Peut-être qu'ils ont autre chose à faire que répondre a ce genre de bruit?
Surtout que c'est ouvert depuis 8 jours seulement… Perso c'est typiquement le genre de ticket qui me gonflerait. Si je devais répondre à ça, j'aurais du mal à ne pas juste mettre un lien vers le dernier commit et fermer le ticket sans plus d'explications.
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . Évalué à 4.
Je crois que j'ai été trop vague ; mon intérêt est professionnel (je peux me trouver d'autres solutions « normales »), et la société pour laquelle je travaille ne vend pas du logiciel : donc contribuer à Seafile sur le temps de l'entreprise c'est ko.
Ensuite on ne se lance pas comme ça sur un projet ; le temps d'apprentissage est long (et ici, il n'y a pas que du C++), et il n'y a pas de docs interne/publique.
Mon sentiment est que lorsque l'on est une entreprise et que l'on vit du produit on ne devrait pas laisser une telle question sans réponse pendant plus d'une semaine.
Ton point de vue me semblerait valable pour un projet perso ou à « implication personnelle » forte (peut-être comme Syncthing), mais là ce n'est pas le cas.
C'est très mauvais pour l'image ; d'ailleurs je leur ai envoyé un mail « commercial » et ils ont réagi (c.f. https://linuxfr.org/nodes/121600/comments/1824425 ), donc ce n'est pas sérieux. Sans ce mail, combien de temps ce ticket serait resté visible ? Quels dégâts sur l'image ?
Et bien ce serait déjà une réponse.
Je le répète des bugs sérieux n'ont juste pas de réponse, et ça me paraît limite.
Comme dit plus haut j'ai envoyé un mail qui a provoqué des réactions, et
- la réponse obtenue sur la vie du projet est la suivante : https://github.com/haiwen/seafile/issues/2368
- la réponse obtenue sur le pb technique est : https://github.com/haiwen/seafile/issues/2366
En bref sur mon bug (qui paralyse une bibliothèque), j'ai un « problème connu, attendez ». Si le problème était connu, alors ils auraient pu créer un ticket : je l'aurais trouvé, je n'aurais pas eu à attendre tellement, et pas à créer un ticket et faire du bruit.
Au final, est-ce que je peux faire confiance quand je sais que leur réaction n'est due qu'à un mail commercial ? Avaient-il réellement connaissance du bug, et travaillaient-ils dessus ? Humpf.
Bon j'ai compris ta position et ta satisfaction globale avec Seafile, et j'espère que tu as la même philosophie lorsque ta production est bloquée sans réponse aucune pendant plusieurs semaines.
Pour ma part quand cela m'arrive, je commence à prévoir une solution alternative, je mets en place une solution dégradée, etc.
[^] # Re: Mort cérébrale, rien que ça...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Si ta production est bloquée pendant des semaines et que tu as dépensé 0€ pour ton logiciel stratégique, c'est probablement qu'il faut revoir la gestion de vos priorités / contrats professionnels, et d'autant plus si vous n'êtes pas "de ce métier là" (dans le sens pas possible d'investiguer soi-même dans le logiciel).
Il faut être sérieux et mettre les moyens correspondant à ses attentes et enjeux.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mort cérébrale, rien que ça...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 5.
Note : je gère une boîte qui développe du logiciel libre et je suis confronté régulièrement à des utilisateurs pro "qui n'ont pas de budget mais sont bloqués par nos bugs et c'est vraiment important pour eux". Parfois même ils sont agressif en mode "c'est abusé des bugs comme ça !"
Mec, tu as dépensé 0€.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . Évalué à 1. Dernière modification le 15 septembre 2020 à 23:55.
Et non le cœur de métier de mon entreprise n'est pas le partage de fichier.
Et oui si le partage de fichier ne fonctionne pas, mon entreprise ne s'arrête pas de vivre (je n'aurais pas pris le temps de poster ici plusieurs semaines après l'incident sinon).
Ensuite sur le question de payer … la version pro ne nous apporterait rien, ne donne droit à rien (pas de support pour <= 9 personnes) … ensuite pour pour 440€/an (10 personnes au lieu de payer +2000€ pour du support), le choix ne manque pas en solution cloud (et dans le cas de Seafile, il y a le coût du serveur et de sa maintenance qu'il faut encore ajouter).
Dans mon post initial je ne leur jette pas la pierre : je demande une alternative.
C'est en répondant à @freem que j'ai bâti une critique de leur gestion de Github, ou généralement de leur communication.
Et le cœur de ma réponse à @freem c'est les explications des raisons pour lesquelles Seafile m'inquiète.
Ton commentaire ne serait donc pas un peu un procès d'intention ?
PS : Pour finir, je ne crois absolument pas qu'en ayant une offre payante j'aurais eu un support efficace ; au plus j'ai le sentiment que j'aurais eu plus vite le « bug connu, attendez ».
PPS : En plus mon entreprise n'aurait aucun souci à payer pour un service, mais je n'avais déjà pas une bonne image de la gestion Seafile (le github qui ne donne pas l'impression de servir à grand chose ; et il faut se rappeler l'imbroglio avec une entreprise allemande) et là ça ne s'est pas amélioré.
J'ai par exemple conseillé à une entreprise dont nous utilisions la version gratuite d'un logiciel (qui couvrait plus que nos besoins déjà) de créer une licence « support » ou autre afin que l'on puisse payer quelque chose pour soutenir (la première licence était par contre vraiment très chère et nous compliquait le logiciel).
Ce n'est donc pas de la radinerie.
[^] # Re: Mort cérébrale, rien que ça...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Mon commentaire est probablement un peu virulent, il ne devrait pas.
Il s'explique par la tendance de nombreux utilisateurs de logiciel libre "clé-en-main" qui se positionnent comme consommateurs purs et qui voient dans le logiciel libre le côté gratuit sans avoir de volonté de pérenniser.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . Évalué à 1.
Je comprends parfaitement et le propos et l'émotion.
On est dans une société de consommation et la seule chose qui ait de la valeur est la consommation.
J'ai le sentiment que le logiciel libre est, pour certains, rangé dans la même case que le soin aux personnes fragiles (pauvres, vieux, etc) : une activité pour la bonne volonté, mais on n'y met pas d'argent.
Peut-on demander aux gens de prendre le temps de réfléchir aux logiciels alors que ces mêmes gens ne prennent pas le temps de réfléchir à la politique, à leurs votes (ou absence de vote) ?
Ensuite il est toujours possible d'imaginer quantité de choses mais il restera toujours la question de la participation des gens.
Peut-être qu'avec ces temps troublés, une conscience différence des enjeux sociétaux émergera dans les années qui viennent ; entre temps il faut serrer les dents et se débattre comme on peut.
PS : pour nourrir la réflexion sur la question du consommateur et de comment a été bâti une société de la consommation : https://www.dailymotion.com/video/x6kqf6i
# Forum
Posté par matteli . Évalué à 1.
As-tu essayé de faire une entrée sur le forum ? Forum
C'est parfois plus réactif de ce côté-là.
# GIT ?
Posté par NeoX . Évalué à 3.
ben oui pour plus de 300.000 fichiers, si c'est du texte (pour obtenir les differences, c'est plus pratique), GIT devrait le faire, et il a plein d'interface possible, CLI, WEB, GUI, etc
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.