Disons que je cherche à faire de l'archivage également ; avec git, il est possible de modifier plusieurs parties du dépôt et de ne commiter/push que ce que l'on veut voir sur le serveur.
En fait Borg impose d'avoir un backup exactement identique à l'original, un peu comme les snapshot au niveau des systèmes de fichier, ou encore comme un seafile qui fonctionnerait en local (avec les précautions d'usage du fait d'être des outils différents évidemment).
C'est dommage mais c'est un choix qui se comprend.
Je suis en train de chercher comment réaliser la tâche suivante :
synchroniser une arborescence de type :
->A
->B
->C
->D
suppression d'une partie de l'arborescence car je considère que seule la sauvegarde peut la conserver ; cela donnerait :
->C
->D
je rajoute des données à l'arborescence ; cela donnerait :
->C
->E
->D
synchroniser à nouveau mais en considérant que ->A et A->B sont toujours présents
Et l'outil ne semble pas permettre de faire cela ; je me trompe ?
PS : en fait je désire sauvegarder une arborescence, mais n'en utiliser qu'une partie au quotidien : si le besoin s'en fait sentir alors je peux sortir ce qui figure dans la sauvegarde et que j'avais retiré
En ce qui concerne les données de ~/.config/borg, je vais jouer avec la variable BORG_BASE_DIR.
Sur ce point on sent l'orientation du logiciel : seules les données de la sauvegarde sont protégées ; grosso modo on se protège contre le voleur de disques, ou les indiscrétions des clouds, etc.
En ce qui concerne python, c'est vraiment une question d'expérience ; je connais C/C++/etc mais pas python et chaque changement me cause un « trauma » (dernier en date la quasi-obligation par Debian d'utiliser des environnements isolés pour installer des programmes externes python) ; alors qu'avec une version statique, je sais que j'arriverai toujours à m'en sortir même dans 10 ans.
Merci pour l'info concernant la version statique : cela me permet d'utiliser et de garder à côté des sauvegardes l'outil qui sait les manipuler :-)
Pour ma part, pour le moment, c'est surtout la dé-duplication en mode « facile » qui m'intéresse.
Bonjour et merci pour la découverte de cet outil que je suis en train de tester.
J'ai toutefois quelques questions qui me tarabustent et comme j'ai la possibilité d'avoir une oreille et des réponses, je saute sur l'opportunité :
- tout ne semble pas si confidentiel que cela car :
--- il y a des données dans $HOME/.config/borg qu'il faut protéger des indiscrets (c.f. lien doc officielle)
--- il y a également le cache qu'il faut protéger (c.f. lien doc officielle)
- la documentation indique qu'il est possible de changer la passphrase, mais le texte est ambigu : changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ? (c.f. lien doc officielle)
- est-il possible d'avoir une sorte de version statique du programme ? Car le fait que le logiciel soit en python me rend un peu nerveux pour ce qui est de la conservation sur la durée (sans même parler de la peur de mettre à jour).
PS : j'ai eu des difficultés à utiliser Markdown (pourtant je l'utilise souvent) alors j'ai utilisé des traits d'union
Étant donné qu'il s'agit de Linux Mint, il faut jeter un œil dans les rapports de bug dans LinuxMint/Ubuntu/Debian.
Mais comme dit avant il y a peu de chances que ce soit un bug dans BTRFS (on n'a pas tous la « chance » de tomber le premier sur un bug) ; il doit y avoir quelque chose qui a provoqué cela. Il est possible d'étudier les logs Windows car si le matériel a changé de comportement/paramétrage, alors cela figurera dedans également.
Est-il possible de monter ce disque dans un autre PC et de le démarrer avec un autre Linux ? (e.g. RescueLinux)
Ensuite pour ce qui est de réparer le FS (ce qui est la réelle question), je ne peux guère aider ; par le passé je tentais de récupérer ce qui était récupérable, puis je repartais à zéro (en ayant tranché sur la cause de l'erreur de disque ; à chaque fois cela a été matériel donc la faute du disque, une fois cela était l'alimentation de la carte mère - était-ce la carte ? l'alim ? je ne sais pas - qui était en tort).
PS : je ne connais pas ccleaner mais RescueLinux avec le composant memtest est fiable (déjà utilisé par le passé ; c'est juste long).
PPS : souvent quand je cherche la cause d'un problème que je rencontre et que je ne trouve rien de pertinent (mais en ayant vraiment bien cherché), c'est que le problème vient de mon côté.
le problème est que je ne vois pas d'erreur matériel et tout semble logiciel (au niveau de BRTFS).
Tout d'abord il faut être sûr de démarrer avec un disque opérationnel et ne rien écrire sur le disque fautif.
Ensuite il est possible de tomber sur un bug de btrfs mais c'est peu probable, donc il faut se poser au moins les questions suivantes :
- que s'est-il passé avant de constater le problème ?
- une mise à jour de Windows ? Une mise à jour du BIOS ? Une coupure d'électricité ?
- peut-être des paramètres au niveau du BIOS ont changé ? (ceux des disques AHCI, SCSI, whatever) ?
- peut-être est-ce plutôt un problème trouvant sa source ailleurs ? (par exemple la RAM via https://www.system-rescue.org/)
- y-a-t-il des erreurs SMART qui sont remontées ? (https://doc.ubuntu-fr.org/smartmontools)
- quel type de disque dur est-ce ? N'y-a-t-il pas des problèmes matériels ou de fiabilités enregistrés relatif à votre disque sur internet ou les forums du constructeur ?
- quelle est la distribution utilisée ? Est-elle en version stable ? La version du noyau est-elle fiable ? Le message d'erreur n'existe-t-il pas quelque part sur le net associé à une version du noyau ?
Dans le foyer nous avons deux téléphones : un sous LineageOs 18.1, l'autre sous OxygenOS 13 ; le tout avec un abonnement 2€ de Free.
Le premier ne peut recevoir ou émettre des MMS sans la data mobile.
Le second peut recevoir des MMS sans la data mobile, mais ne peut émettre qu'avec la data mobile.
Donc soit un peu de hack/configuration, soit on allume la data mobile quand il y a le besoin.
Il y ressemble par certains aspects pédagogiques mais pas du tout sur la forme : c'était du texte, très sérieux (pas de blagues ou de tâches de confiture comme pour l'ancienne édition), et sans illustration, du moins je n'ai pas le souvenir d'un éléphant comme dans l'édition « récente ».
Peut-être mon livre s'inspirait-il de celui-ci car le plan a l'air assez proche, et que je me rappelle les avertissements concernant les différents dialectes.
il y a des millions d'années de cela (i.e. dans mes années étudiantes), j'ai ouvert un livre sur le LISP (par pure curiosité) et avais beaucoup apprécié celui-ci : il présentait quelques mots clefs seulement (affectation, tête, queue, et un ou deux autres) et proposait de construire tout le reste au travers d'exercices.
J'avais trouvé le langage super (c'est ainsi que j'ai appris la récursivité), mais je l'ai laissé ensuite sur le côté : il ne m'avait finalement qu'appris à penser ; c'était déjà bien.
Cela dit-il quelque chose à quelqu'un ? Quelqu'un aurait-il une idée de l'ouvrage ?
PS : je souhaiterais l'utiliser pour le passer à mes cht'iots.
J'avoue n'avoir pas envie de chercher la RFC qui va bien.
Les seules choses que je peux dire sont :
- avec l'appli par défaut et sans data, je reçois bien la notification de réception
- le ticket existe et nulle part dedans il est fait mention de « pas possible »
Mais t'as peut-être raison, je dirais même que tu as sûrement raison : l'aplomb affiché est convainquant.
Précisons le propos : QKSMS ne sait pas gérer les MMS quand la data est désactivée.
Cela ne signifie pas qu'il ne sait pas récupérer le message, cela signifie qu'il ne sait pas le gérer.
En l'espèce, il devrait :
- notifier l'utilisateur de la présence d'un MMS
- une fois la data rétablie télécharger le MMS, ou proposer le téléchargement via notification, ou permettre à l'utilisateur de le télécharger
En l'état avec QKSMS et avec data désactivée, on ne sait même pas qu'un MMS est arrivé, et après rétablissement de la data, il n'est pas possible de télécharger le MMS.
Tout est expliqué sur le ticket pointé dans le premier post.
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.
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.
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?
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.
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.
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 ?
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.
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.
J'ai envoyé avec mon adresse pro le mail suivant :
Bonjour
Nous sommes actuellement en train d'évaluer des solutions de stockage en ligne, votre solution paraît intéressante car elle nous permettrait de garder le contrôle sur nos données.
Nous souhaiterions être en mesure d'évaluer le produit avec 10 utilisateur, pour une cible final de 700 utilisateurs si nous retenons votre solution.
Toutefois avant cela, nous nous posons des questions quant à la maintenance du produit car le le compte Github n'a pas l'air très vivant (ici https://github.com/haiwen/seafile/issues ) : il y a beaucoup de vieux tickets qui n'ont aucune réponse ou « lecture ». La dernière réponse de quelqu'un de chez vous semble dater d'avril. De plus certains tickets semblent sérieux.
Pourriez-vous me donner des informations à propos du produit et son statut ?
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.
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 :
2.0.2 (2020/05/23)
[Mac] Support syncing encrypted libraries
[Win] Support change cache location
[Win] Improve account switching behaviors
[Win] Other bug fixes
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).
Je connais des projets plus mort.
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.
Qu'est-ce qu'il te manque exactement ?
Des réponses pour ce qui est des bugs remontés. J'en ai eu au moins deux, qui sont sérieux et qui n'ont aucune réponse et dont la seule solution a été de réinitialiser le dépôt ou le client.
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 : pour ma part je ne prendrais pas les définitions d'un philosophe sur un objet politique, ou plutôt c'est sympa mais faut aller récupérer plein de définitions ailleurs ; ce qui est le B.A.BA. de la philosophie.
Depuis […] la crise sanitaire […], Emmanuel Macron a dit à plusieurs reprises qu’il veillerait à défendre l’État-providence […] : « Ce que révèle d’ores et déjà cette pandémie, a-t-il dit lors de son allocution au pays le 12 mars, c’est que la santé gratuite sans condition de revenu, de parcours ou de profession, [pour] notre État-providence, ne sont pas des coûts ou des charges mais des biens précieux, des atouts indispensables quand le destin frappe […]. Il est des biens et des services qui doivent être placés en dehors des lois du marché. »
À la demande d’Emmanuel Macron, la Caisse des dépôts travaille à un plan pour l’hôpital public. […] . Au lieu de défendre l’intérêt général, il vise à accélérer la marchandisation de la santé et sa privatisation rampante.
Après on peut toujours imaginer que Notre Bien Aimé Président pense qu'en privatisant la santé, elle sera meilleure pour tout le monde.
Pour ma part, je ne crois à rien de ce qui sort de sa bouche ou de son gouvernement.
[^] # Re: borgbackup peut-il ignorer des modifications ?
Posté par lem__mel . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 1.
Disons que je cherche à faire de l'archivage également ; avec git, il est possible de modifier plusieurs parties du dépôt et de ne commiter/push que ce que l'on veut voir sur le serveur.
En fait Borg impose d'avoir un backup exactement identique à l'original, un peu comme les snapshot au niveau des systèmes de fichier, ou encore comme un seafile qui fonctionnerait en local (avec les précautions d'usage du fait d'être des outils différents évidemment).
C'est dommage mais c'est un choix qui se comprend.
En tout cas merci pour cette découverte.
# borgbackup peut-il ignorer des modifications ?
Posté par lem__mel . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 2.
Je suis en train de chercher comment réaliser la tâche suivante :
synchroniser une arborescence de type :
suppression d'une partie de l'arborescence car je considère que seule la sauvegarde peut la conserver ; cela donnerait :
je rajoute des données à l'arborescence ; cela donnerait :
synchroniser à nouveau mais en considérant que
->AetA->Bsont toujours présentsEt l'outil ne semble pas permettre de faire cela ; je me trompe ?
PS : en fait je désire sauvegarder une arborescence, mais n'en utiliser qu'une partie au quotidien : si le besoin s'en fait sentir alors je peux sortir ce qui figure dans la sauvegarde et que j'avais retiré
[^] # Re: Quelques questions
Posté par lem__mel . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 3.
En ce qui concerne les données de
~/.config/borg, je vais jouer avec la variable BORG_BASE_DIR.Sur ce point on sent l'orientation du logiciel : seules les données de la sauvegarde sont protégées ; grosso modo on se protège contre le voleur de disques, ou les indiscrétions des clouds, etc.
En ce qui concerne python, c'est vraiment une question d'expérience ; je connais C/C++/etc mais pas python et chaque changement me cause un « trauma » (dernier en date la quasi-obligation par Debian d'utiliser des environnements isolés pour installer des programmes externes python) ; alors qu'avec une version statique, je sais que j'arriverai toujours à m'en sortir même dans 10 ans.
Merci pour l'info concernant la version statique : cela me permet d'utiliser et de garder à côté des sauvegardes l'outil qui sait les manipuler :-)
Pour ma part, pour le moment, c'est surtout la dé-duplication en mode « facile » qui m'intéresse.
[^] # Re: Quelques questions
Posté par lem__mel . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 3.
C'est ce que j'avais compris mais j'ai eu un doute car je ne voyais pas l'intérêt de ce paragraphe : quand la clef est compromise, tout est perdu.
Je suppose que la documentation se voulait pédagogique.
Merci pour la réponse !
# Quelques questions
Posté par lem__mel . En réponse au lien Présentation de BorgBackup, l'un des meilleurs outils de sauvegarde disponibles sous Linux. Évalué à 4.
Bonjour et merci pour la découverte de cet outil que je suis en train de tester.
J'ai toutefois quelques questions qui me tarabustent et comme j'ai la possibilité d'avoir une oreille et des réponses, je saute sur l'opportunité :
- tout ne semble pas si confidentiel que cela car :
--- il y a des données dans $HOME/.config/borg qu'il faut protéger des indiscrets (c.f. lien doc officielle)
--- il y a également le cache qu'il faut protéger (c.f. lien doc officielle)
- la documentation indique qu'il est possible de changer la passphrase, mais le texte est ambigu : changing the passphrase after passphrase and borg key got compromised does not protect future (nor past) backups to the same repository ; qu'est-ce que cela signifie ? (c.f. lien doc officielle)
- est-il possible d'avoir une sorte de version statique du programme ? Car le fait que le logiciel soit en python me rend un peu nerveux pour ce qui est de la conservation sur la durée (sans même parler de la peur de mettre à jour).
PS : j'ai eu des difficultés à utiliser Markdown (pourtant je l'utilise souvent) alors j'ai utilisé des traits d'union
[^] # Re: Le père du problème ?
Posté par lem__mel . En réponse au message Besoins de l'aide d'un expert du BRTFS. Évalué à 3.
Étant donné qu'il s'agit de Linux Mint, il faut jeter un œil dans les rapports de bug dans LinuxMint/Ubuntu/Debian.
Mais comme dit avant il y a peu de chances que ce soit un bug dans BTRFS (on n'a pas tous la « chance » de tomber le premier sur un bug) ; il doit y avoir quelque chose qui a provoqué cela. Il est possible d'étudier les logs Windows car si le matériel a changé de comportement/paramétrage, alors cela figurera dedans également.
Est-il possible de monter ce disque dans un autre PC et de le démarrer avec un autre Linux ? (e.g. RescueLinux)
Ensuite pour ce qui est de réparer le FS (ce qui est la réelle question), je ne peux guère aider ; par le passé je tentais de récupérer ce qui était récupérable, puis je repartais à zéro (en ayant tranché sur la cause de l'erreur de disque ; à chaque fois cela a été matériel donc la faute du disque, une fois cela était l'alimentation de la carte mère - était-ce la carte ? l'alim ? je ne sais pas - qui était en tort).
PS : je ne connais pas ccleaner mais RescueLinux avec le composant memtest est fiable (déjà utilisé par le passé ; c'est juste long).
PPS : souvent quand je cherche la cause d'un problème que je rencontre et que je ne trouve rien de pertinent (mais en ayant vraiment bien cherché), c'est que le problème vient de mon côté.
[^] # Re: Le père du problème ?
Posté par lem__mel . En réponse au message Besoins de l'aide d'un expert du BRTFS. Évalué à 2. Dernière modification le 05 juillet 2023 à 11:42.
le problème est que je ne vois pas d'erreur matériel et tout semble logiciel (au niveau de BRTFS).
Tout d'abord il faut être sûr de démarrer avec un disque opérationnel et ne rien écrire sur le disque fautif.
Ensuite il est possible de tomber sur un bug de btrfs mais c'est peu probable, donc il faut se poser au moins les questions suivantes :
- que s'est-il passé avant de constater le problème ?
- une mise à jour de Windows ? Une mise à jour du BIOS ? Une coupure d'électricité ?
- peut-être des paramètres au niveau du BIOS ont changé ? (ceux des disques AHCI, SCSI, whatever) ?
- peut-être est-ce plutôt un problème trouvant sa source ailleurs ? (par exemple la RAM via https://www.system-rescue.org/)
- y-a-t-il des erreurs SMART qui sont remontées ? (https://doc.ubuntu-fr.org/smartmontools)
- quel type de disque dur est-ce ? N'y-a-t-il pas des problèmes matériels ou de fiabilités enregistrés relatif à votre disque sur internet ou les forums du constructeur ?
- quelle est la distribution utilisée ? Est-elle en version stable ? La version du noyau est-elle fiable ? Le message d'erreur n'existe-t-il pas quelque part sur le net associé à une version du noyau ?
En bref il y a plein d'axes de recherche.
Bon courage.
[^] # Re: Sûr?
Posté par lem__mel . En réponse au message Forfait Free à 2€ et MMS illimités qui utilise les données mobiles payantes.. Évalué à 3. Dernière modification le 08 juin 2023 à 09:53.
Dans le foyer nous avons deux téléphones : un sous LineageOs 18.1, l'autre sous OxygenOS 13 ; le tout avec un abonnement 2€ de Free.
Le premier ne peut recevoir ou émettre des MMS sans la data mobile.
Le second peut recevoir des MMS sans la data mobile, mais ne peut émettre qu'avec la data mobile.
Donc soit un peu de hack/configuration, soit on allume la data mobile quand il y a le besoin.
PS : Voici un petit journal qui parlait du MMS et de sa récupération : https://linuxfr.org/users/raphj/journaux/reception-d-un-mms-difficile
[^] # Re: Question sur un vieux livre
Posté par lem__mel . En réponse au journal Les nouveautés folles furieuses de Common Lisp en 2022: la revue. Évalué à 1.
je viens de jeter un œil, et ce n'est pas le même.
Bah, ça fera partie des choses de « l'enfance » ayant disparues :-)
Merci.
[^] # Re: Question sur un vieux livre
Posté par lem__mel . En réponse au journal Les nouveautés folles furieuses de Common Lisp en 2022: la revue. Évalué à 2.
Il y ressemble par certains aspects pédagogiques mais pas du tout sur la forme : c'était du texte, très sérieux (pas de blagues ou de tâches de confiture comme pour l'ancienne édition), et sans illustration, du moins je n'ai pas le souvenir d'un éléphant comme dans l'édition « récente ».
Peut-être mon livre s'inspirait-il de celui-ci car le plan a l'air assez proche, et que je me rappelle les avertissements concernant les différents dialectes.
# Question sur un vieux livre
Posté par lem__mel . En réponse au journal Les nouveautés folles furieuses de Common Lisp en 2022: la revue. Évalué à 5.
il y a des millions d'années de cela (i.e. dans mes années étudiantes), j'ai ouvert un livre sur le LISP (par pure curiosité) et avais beaucoup apprécié celui-ci : il présentait quelques mots clefs seulement (affectation, tête, queue, et un ou deux autres) et proposait de construire tout le reste au travers d'exercices.
J'avais trouvé le langage super (c'est ainsi que j'ai appris la récursivité), mais je l'ai laissé ensuite sur le côté : il ne m'avait finalement qu'appris à penser ; c'était déjà bien.
Cela dit-il quelque chose à quelqu'un ? Quelqu'un aurait-il une idée de l'ouvrage ?
PS : je souhaiterais l'utiliser pour le passer à mes cht'iots.
[^] # Re: Problème d'appli on dirait
Posté par lem__mel . En réponse au message Temps d'envoi / réception SMS / XMPP.. Évalué à 1.
J'avoue n'avoir pas envie de chercher la RFC qui va bien.
Les seules choses que je peux dire sont :
- avec l'appli par défaut et sans data, je reçois bien la notification de réception
- le ticket existe et nulle part dedans il est fait mention de « pas possible »
Mais t'as peut-être raison, je dirais même que tu as sûrement raison : l'aplomb affiché est convainquant.
[^] # Re: Problème d'appli on dirait
Posté par lem__mel . En réponse au message Temps d'envoi / réception SMS / XMPP.. Évalué à 1.
Précisons le propos : QKSMS ne sait pas gérer les MMS quand la data est désactivée.
Cela ne signifie pas qu'il ne sait pas récupérer le message, cela signifie qu'il ne sait pas le gérer.
En l'espèce, il devrait :
- notifier l'utilisateur de la présence d'un MMS
- une fois la data rétablie télécharger le MMS, ou proposer le téléchargement via notification, ou permettre à l'utilisateur de le télécharger
En l'état avec QKSMS et avec data désactivée, on ne sait même pas qu'un MMS est arrivé, et après rétablissement de la data, il n'est pas possible de télécharger le MMS.
Tout est expliqué sur le ticket pointé dans le premier post.
# Problème d'appli on dirait
Posté par lem__mel . En réponse au message Temps d'envoi / réception SMS / XMPP.. Évalué à 2.
J'ai le même problème et j'avais corrigé cela en utilisant une autre appli : QKSMS
Le hic est que QKSMS ne sait pas gérer les MMS reçus quand la data est désactivée :-( (source : https://github.com/moezbhatti/qksms/issues/118 ).
Je fais donc avec ces décalages.
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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 lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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: C'est une excellente question...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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: syncthing ...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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
[^] # Re: Partage de fichiers
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. Évalué à 1.
Intéressant ! Je jetterai un œil un peu plus tard.
Merci pour la piste.
[^] # Re: syncthing ...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. Évalué à 1.
Déjà vu mais il ne répond pas par exemple au besoin d'historisation :-(
[^] # Re: C'est une excellente question...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. Évalué à 2.
C'est une piste. Merci.
[^] # Re: Mort cérébrale, rien que ça...
Posté par lem__mel . En réponse au message Seafile est-il abandonné, y-a-t-il une alternative ?. É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: Le logiciel libre c'est politique (sinon, on parlerait d'Open Source)
Posté par lem__mel . En réponse au journal oh et puis merde.... dlfp, c'est vraiment censé être politique?. Évalué à -1. Dernière modification le 26 avril 2020 à 23:30.
Concernant le bonhomme face à Bégaudeau (et ce sujet est abordé) : https://www.youtube.com/watch?v=7lnvECzZIMI
PS : pour ma part je ne prendrais pas les définitions d'un philosophe sur un objet politique, ou plutôt c'est sympa mais faut aller récupérer plein de définitions ailleurs ; ce qui est le B.A.BA. de la philosophie.
[^] # Re: Naïf ?
Posté par lem__mel . En réponse au lien Lettre du médecin André Grimaldi à ses collègues de La Pitié Salpétrière - lemonde.fr/blog. Évalué à 3.
En effet, il n'y a pas besoin d'attendre.
Après on peut toujours imaginer que Notre Bien Aimé Président pense qu'en privatisant la santé, elle sera meilleure pour tout le monde.
Pour ma part, je ne crois à rien de ce qui sort de sa bouche ou de son gouvernement.
PS : Source Médiapart : https://www.mediapart.fr/journal/france/010420/hopital-public-la-note-explosive-de-la-caisse-des-depots