Fuite de mémoire dans Open Office et Libre Office : une solution ?

[Ghost-Raider]

Bonjour,

Je viens de passer le message ci-dessous dans
fr.comp.applications.bureautique mais ce groupe est en état
d'hibernation quasi perpétuelle alors je le publie ici car je reconnais
certains noms.


J’utilise Open Office sous Windows 10 ou Libre Office sous Linux Mint
pour ma compta personnelle qui recouvre une quarantaine d'années.

Elle est organisée en partie double sous forme de 3 fichiers/tableurs
comprenant 13 ou 14 années successives et pour chaque année 12 tableaux
mensuels qui eux-même sont divisés en une centaine de colonnes et 60
lignes environ.

Pourquoi 3 fichiers et pas un seul pour les 40 années ? Parce que la
limite du nombre de tableaux dans un fichier est de 256 et que par
ailleurs, les temps de chargement et d'enregistrement sont déjà assez longs.

Les trois fichiers sont légers : moins de 1 MO chaque ce qui s'explique
par le fait que la plupart des cases sont vides.

J'en viens à mes problèmes.

Bug n° 1
On sait que Libre Office est un fork de Open Office qui lui-même est un
héritage de Star Office.
Star Office présentait un bug gênant même sur des petits fichiers : de
temps en temps, ils se plantait sans raison apparente. Pour y pallier,
il enregistrait en flux continu toutes les opérations. En cas de
plantage, il proposait à sa réouverture de recharger le fichier dans son
dernier état. Ce contournement fonctionnait bien et il a été repris dans
Open Office puis dans Libre Office, mais la cause n'en a jamais été
corrigée.

Bug n°2.
Open Office et Libre office partagent un autre bug beaucoup plus gênant.
L'occupation mémoire augmente progressivement à chaque opération car la
mémoire utilisée n'est jamais libérée. Elle augmente progressivement
pour atteindre et dépasser 1,2 GO ou plus et là, le programme se plante.
On le voit en examinant le fichier soffice.bin .
Au départ, il occupe déjà volontiers 200 à 400 MO, ce qui est très
étonnant, puis, il augmente lentement mais sûrement. Si on déplace dans
un tableau un certain nombre de cellules, par exemple pour insérer des
lignes ou des colonnes, soffice.bin augmente brusquement et atteint
facilement 800 ou 900 MO. C'est à l'enregistrement que ça se gâte car
alors soffice.bin dépasse 1, 2 ou 1,3 GO et le programme se plante, sans
doute en raison de la limite de 1,6 GO des applications 32 bits.
Contournement : fermer et rouvrir Open Office ou Libre Office pour faire
redescendre soffice.bin. C'est la solution des forums usenet (sans rire).

Bug n°3
Uniquement Libre Office : de temps en temps, Libre Office se ferme tout
simplement sans prévenir et le fichier de sauvegarde au fil de l'eau
n'est pas proposé
à la réouverture, tout le travail récent est perdu.

Le bug n°2 est référencé sur usenet mais aucune solution n'a jamais été
apportée.
Par exemple :
https://bz.apache.org/ooo/show_bug.cgi?id=94528
ou bien :
https://ask.libreoffice.org/t/writer-memory-leak-libreoffice-7-3-0/74053

Tous ces bugs sont observables sous Windows ou sous Linux.
Pour y pallier, je surveille l'occupation mémoire dans un petit coin et
je ferme puis rouvre le logiciel pour la faire redescendre mais c'est un
pis-aller.

Quelqu'un a-t-il une solution ?

[Th.A.C]

Le 07/10/2023 à 15:15, Ghost-Raider a écrit :

> Bug n°2.
> Open Office et Libre office partagent un autre bug beaucoup plus gênant.
> L'occupation mémoire augmente progressivement à chaque opération car la
> mémoire utilisée n'est jamais libérée. Elle augmente progressivement
> pour atteindre et dépasser 1,2 GO ou plus et là, le programme se plante.
> On le voit en examinant le fichier soffice.bin .
> Au départ, il occupe déjà volontiers 200 à 400 MO, ce qui est très
> étonnant, puis, il augmente lentement mais sûrement. Si on déplace dans
> un tableau un certain nombre de cellules, par exemple pour insérer des
> lignes ou des colonnes, soffice.bin augmente brusquement et atteint
> facilement 800 ou 900 MO. C'est à l'enregistrement que ça se gâte car
> alors soffice.bin dépasse 1, 2 ou 1,3 GO et le programme se plante, sans
> doute en raison de la limite de 1,6 GO des applications 32 bits.
> Contournement : fermer et rouvrir Open Office ou Libre Office pour faire
> redescendre soffice.bin. C'est la solution des forums usenet (sans rire).

Il me semble qu'on en a déjà parlé et je t'avais proposé de réduire le
nombre d'annulation qui est de 100 par défaut.

https://azurplus.fr/comment-modifier-le-nombre-dactions-que-vous-pouvez-annuler-dans-libreoffice/


Tu avais testé?

[Thierry HOUX]

Ton utilisation est très inhabituelle voire carrément atypique.
Pour ma part, je suis incapable de t'aider, et pourtant j'ai bien secoué
OO puis LO avec des macros que j'ai programmées et appliquées sur
plusieurs milliers de lignes, sans jamais réussir à les planter.

[Dominique]

Le 08/10/2023 à 16:12, Thierry HOUX a écrit :

> Ton utilisation est très inhabituelle voire carrément atypique.
> Pour ma part, je suis incapable de t'aider, et pourtant j'ai bien secoué
> OO puis LO avec des macros que j'ai programmées et appliquées sur
> plusieurs milliers de lignes, sans jamais réussir à les planter.

J'utilise LIBO depuis bien longtemps, et OOo avant. Ils n'ont jamais
planté. Et pourtant, tout comme toi, je les soumettais et soumets à la
torture avec de très gros fichiers.

--
Dominique
Esto quod es

[Ghost-Raider]

Je me souviens avoir parlé de ce problème sur plusieurs groupe mais ici,
je ne me souviens pas, ni du message azurplus. Je vais rechercher,

--
J'ai beau faire, tout m'intéresse. (Paul Valéry)

[Ghost-Raider]

Le 08/10/2023 à 16:12, Thierry HOUX a écrit :

Oui, c'est vraiment curieux. Voir éventuellement ma réponse à Thierry
Beauregard sur fr.comp.applications.bureautique

[Ghost-Raider]

[Alf92]

Ghost-Raider (le 07/10/2023 à 15:15:52) :

> Bug n°2.
> Open Office et Libre office partagent un autre bug beaucoup plus gênant.
> L'occupation mémoire augmente progressivement à chaque opération car la
> mémoire utilisée n'est jamais libérée. Elle augmente progressivement
> pour atteindre et dépasser 1,2 GO ou plus et là, le programme se plante.
> On le voit en examinant le fichier soffice.bin .
> Au départ, il occupe déjà volontiers 200 à 400 MO, ce qui est très
> étonnant, puis, il augmente lentement mais sûrement. Si on déplace dans
> un tableau un certain nombre de cellules, par exemple pour insérer des
> lignes ou des colonnes, soffice.bin augmente brusquement et atteint
> facilement 800 ou 900 MO. C'est à l'enregistrement que ça se gâte car
> alors soffice.bin dépasse 1, 2 ou 1,3 GO et le programme se plante, sans
> doute en raison de la limite de 1,6 GO des applications 32 bits.
> Contournement : fermer et rouvrir Open Office ou Libre Office pour faire
> redescendre soffice.bin. C'est la solution des forums usenet (sans rire).

ça donne quoi sur un ordi 64bits gavé de mémoire (16Go ou plus) ?
et ça le fait endépendemment du format utilisé (ODS, XLS ou XLSX) ?

[Ghost-Raider]

Sauf erreurs, Open Office et Libre Office sont en 32 bits.
Le problème de fuite de mémoire de soffice.bin qui est un fichier vieux
comme Hérode date de Star Office, logiciel génial malheureusement tué
par les gens d'Open Office qui l'ont bêtement émasculé ce qui a donné
Open Office puis Libre Office, beaucoup moins universels, mais bon...

Mon PC W10 fait 12 GO de RAM et soffice.bin se dilate comme un ballon de
baudruche.
Mon PC Linux fait 16 GO de RAM et c'est pareil, soffice.bin devient
énorme dès l'ouverture de LO.

Ce problème de soffice.bin n'existe que dans OO et LO, mais pas dans
MS-EXCEL ou MS-WORD.
C'est rageant parce que je tiens à n'utiliser que des logiciels libres
et là, je suis coincé.

Et comme LO sous Linux bugue plutôt plus que OO sous Windows, je reste
sous Windows pour l'instant, bien obligé.

J'imagine que c'est toute la structure initiale de l'information qui est
foireuse et qu'il faudrait tout casser pour résoudre ce problème qui ne
semble pas vraiment remuer les foules et qui est, finalement, facile à
contourner.

[Nicolas George]

Ghost-Raider , dans le message <ug19sv$ht$2...@dont-email.me>, a écrit :

> Sauf erreurs, Open Office et Libre Office sont en 32 bits.

Erreur.

~ $ file /usr/lib/libreoffice/program/soffice.bin
/usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB pie executable […]

> C'est rageant parce que je tiens à n'utiliser que des logiciels libres
> et là, je suis coincé.

Suggestion : pour faire de la comptabilité, utiliser un logiciel de
comptabilité.

[Christophe PEREZ]

Le 09 Oct 2023 16:54:25 GMT, Nicolas George a écrit :

> ~ $ file /usr/lib/libreoffice/program/soffice.bin
> /usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB pie executable
> […]

Si j'ai bien compris, il traite ici un problème Windows...
Il sait que ce n'est pas l'endroit, mais il a vu de a lumière...
Il démontre une nouvelle fois le respect qu'il a pour les lecteurs de ce
groupe.
Vivement qu'il soit rangé avec ptilou pour ne pas avoir à le supporter par
les réponses indirectes ;)

[christian]

Le Mon, 9 Oct 2023 18:31:27 +0200, Ghost-Raider a écrit :

> Sauf erreurs, Open Office et Libre Office sont en 32 bits.

Comment l'as-tu déterminé?

Chez moi (Debian 12),Libre-office est en 64 bits
(sauf erreur de ma part)

> Mon PC Linux fait 16 GO de RAM et c'est pareil, soffice.bin devient
> énorme dès l'ouverture de LO.

chez moi, il ne bouge pas d'un octet (14672 octets) quoi qu'il arrive

Est-ce qu'on parle du même fichiers?

> J'imagine que c'est toute la structure initiale de l'information qui est
> foireuse et qu'il faudrait tout casser pour résoudre ce problème qui ne
> semble pas vraiment remuer les foules et qui est, finalement, facile à
> contourner.

ben, s'il faut tout casser, c'est pas si simple :-)

--
Christian

[Ghost-Raider]

Le 09/10/2023 à 18:54, Nicolas George a écrit :
> Ghost-Raider , dans le message <ug19sv$ht$2...@dont-email.me>, a écrit :
>> Sauf erreurs, Open Office et Libre Office sont en 32 bits.
>
> Erreur.
>
> ~ $ file /usr/lib/libreoffice/program/soffice.bin
> /usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB pie executable […]

Effectivement, ma version d'Open Office est en 32 bits mais ma version
LO est bien en 64 bits ce qui répond à la demande d'Alf 92 : que se
passerait-il dans un PC de 16 GO sous 64 bits ?
La réponse est la même, hélas : Libre Office sur mon PC Linux 16 GO en
64 bits présente le bug de fuite de mémoire avec plantage.

>
>> C'est rageant parce que je tiens à n'utiliser que des logiciels libres
>> et là, je suis coincé.
>
> Suggestion : pour faire de la comptabilité, utiliser un logiciel de
> comptabilité.

Ce n'est pas la question, mais j'y réponds quand même.
J'ai cherché des programmes de compta, sous Windows ou sous Linux. je
n'ai rien trouvé de satisfaisant.
Ou bien on trouve des programmes libres relativement simplistes mais
comme je l'ai dit plus haut, non pluri-entités ce qui les exclut, ou
bien on trouve des programmes payants avec toutes les fonctions :
entités multiples, compta budgétaire, analytique, clients, fournisseurs,
stocks, personnel, états de synthèse etc.. etc.. mais bien trop lourds à
manier.

Mon système de tableaux pluri-entités en partie double est d'une
simplicité biblique puisque je me contente de mettre des sommes dans des
cases déjà présentes.et que j'ai les synthèses à la simple lecture.

[Ghost-Raider]

Le 09/10/2023 à 19:13, christian a écrit :
> Le Mon, 9 Oct 2023 18:31:27 +0200, Ghost-Raider a écrit :
>
>> Sauf erreurs, Open Office et Libre Office sont en 32 bits.
>
> Comment l'as-tu déterminé?

De mémoire, mais je me suis trompé. J'ai répondu à Nicolas George : chez
moi : OO en 32 bits, LO en 64 bits, avec toujours la même fuite.

>
> Chez moi (Debian 12),Libre-office est en 64 bits
> (sauf erreur de ma part)

Pas d'erreur de ta part.

>
>> Mon PC Linux fait 16 GO de RAM et c'est pareil, soffice.bin devient
>> énorme dès l'ouverture de LO.
>
> chez moi, il ne bouge pas d'un octet (14672 octets) quoi qu'il arrive
>
> Est-ce qu'on parle du même fichiers?

Il n'y a qu'une instance de soffice.bin à ma connaissance, qui apparaît
dès que je lance le logiciel et qui disparaît dès que je le ferme,
constatations faite sous Windows et sous Linux.
Et c'est bien ce fichier qui enfle jusqu'à dépasser 1 GO et qui finit
par se planter.

>> J'imagine que c'est toute la structure initiale de l'information qui est
>> foireuse et qu'il faudrait tout casser pour résoudre ce problème qui ne
>> semble pas vraiment remuer les foules et qui est, finalement, facile à
>> contourner.
>
> ben, s'il faut tout casser, c'est pas si simple :-)
>

Non, c'est certainement trop compliqué puisque cette fuite de mémoire
date de Star Office dont ma version, la 5.2, a plus de 20 ans d'âge et
n'a jamais été corrigée.
On peut consulter sur le web des tas de messages sur ce problème, jamais
résolu.

[Ghost-Raider]

Le 09/10/2023 à 19:08, Christophe PEREZ a écrit :
> Le 09 Oct 2023 16:54:25 GMT, Nicolas George a écrit :
>
>> ~ $ file /usr/lib/libreoffice/program/soffice.bin
>> /usr/lib/libreoffice/program/soffice.bin: ELF 64-bit LSB pie executable
>> […]
>
> Si j'ai bien compris, il traite ici un problème Windows...

Non, tu n'as pas compris, ce n'est pas un problème Windows, c'est un
problème de fuite de mémoire d'Open Office et de Libre Office, sous
*LINUX* et sous Windows.

Relis le message de départ STP avant de démontrer que tu ne lis pas les
fils.

> Il sait que ce n'est pas l'endroit, mais il a vu de a lumière...
> Il démontre une nouvelle fois le respect qu'il a pour les lecteurs de ce
> groupe.

A chaque fois que tu écris quelque chose, tu démontres que tu es
simplement mu par une certaine sociopathie.

> Vivement qu'il soit rangé avec ptilou pour ne pas avoir à le supporter par
> les réponses indirectes ;)

Toujours des petites méchancetés. Tu as dû être harcelé à l'école pour
te comporter ainsi.

A propos, je t'ai chargé d'écrire un processus en langage de contrôle
Linux, justement sur ce problème de fuite de mémoire.
Tu ne t'en souviens apparemment pas.

Je t'ai écrit le 13/9/2023 à 18h46 :

".. je te soumets le problème, sérieusement : comment corriger ou
éviter la fuite mémoire dont je parle, qui existe dans Libre Office et
dans Open Office, qui est parfaitement connue sur le Web et qui perdure
de version en version ?

Allez, je te donne une piste : cette fuite mémoire est liée à une
insuffisance d'affectation de la mémoire quand le logiciel réorganise la
base de données. Il faudrait tout récrire et personne n'a le temps.

Contournement : tu vas écrire en langage de contrôle un processus qui
surveille l'occupation mémoire, qui sauvegarde automatiquement le
fichier de travail avant que le logiciel se plante, qui ferme le
logiciel, qui le rouvre à neuf et qui recharge le fichier en cours."


Où en es-tu de l'écriture de ce processus ?

[Christian Gaudin]

Le Mon, 9 Oct 2023 20:38:43 +0200, Ghost-Raider a écrit :

>> Suggestion : pour faire de la comptabilité, utiliser un logiciel de
>> comptabilité.
>
> Ce n'est pas la question, mais j'y réponds quand même.
> J'ai cherché des programmes de compta, sous Windows ou sous Linux. je
> n'ai rien trouvé de satisfaisant.
> Ou bien on trouve des programmes libres relativement simplistes mais
> comme je l'ai dit plus haut, non pluri-entités ce qui les exclut, ou
> bien on trouve des programmes payants avec toutes les fonctions :
> entités multiples, compta budgétaire, analytique, clients, fournisseurs,
> stocks, personnel, états de synthèse etc.. etc.. mais bien trop lourds à
> manier.

tu as regardé du côté de Gnucash ?
https://www.gnucash.org/

libre mais pas simpliste.
non-payant mais peut-être trop lourd?

--
Christian

[Thierry HOUX]

Peut-être pas un problème dû à soffice.bin mais qui a des conséquences sur
ce dernier. Se méfier de la conséquence visible et de la cause qui peut-
être ailleurs, en l'occurrence calc peut-être?

[Ghost-Raider]

Oui, merci de le mentionner.
Avant de passer à mon système de tableaux, j'ai exploré divers
logiciels dont GnuCash.

C'est un logiciel d'origine australienne francisé très complet et qui
demande un certain temps de formation et d’adaptation, du plan
comptable, des schémas d'écritures et des états de restitution en
particulier.

Je ne l'ai finalement pas retenu pour plusieurs raisons :

1 - la passation d'une écriture est plutôt longue, l'ergonomie est
perfectible,
Il me faudrait bien 30 secondes pour passer une écriture, or j'ai près
de 30000 écritures dans mes tableaux ; dans mon système actuel une
écriture me prends 5 secondes,

2 - et surtout, il est mono-entité ; des utilisateurs ont essayé d'y
porter remède, mais ça reste du bricolage :
https://lists.gnucash.org/pipermail/gnucash-user/2015-January/057906.html

On peut évidemment créer autant d'entités qu'on veut mais leur
combinaison n'est pas prévue.
Ainsi, par exemple, un virement de fonds d'un de mes comptes à un compte
de ma femme se traduira par une écriture dans chaque entité mais elles
ne seront pas consolidées dans les états de synthèse.

Donc, impossible sans grosses complications d'obtenir des états
consolidés (combinés serait le terme exact), dont le contenu serait
d'ailleurs bien moins clair que des tableaux combinés qui permettent
l'analyse "hélicoptère".

[Ghost-Raider]

Le 07/10/2023 à 18:19, Th.A.C a écrit :

Je viens de m'apercevoir que j'ai parlé de ce problème en mai.
Je l'avais complètement oublié.
Merci de rafraîchir ma mémoire défaillante.
Donc, rebelote, je vais voir si cette limite change quelque chose.

[Eric M]

Le 10/10/2023 à 17:02, Ghost-Raider a écrit :

> Je viens de m'apercevoir que j'ai parlé de ce problème en mai.
> Je l'avais complètement oublié.
> Merci de rafraîchir ma mémoire défaillante.

Il y avait donc bien une fuite de mémoire (ok, je sors).

[Ghost-Raider]

Non, en fait, ce n'était pas en mai mais en septembre...
Heu, non... je ne sais plus.. ça devait être dans un autre groupe, mais
lequel ?

Tiens, tu la connais celle-là ?
- Docteur, Docteur, sauvez-moi ! J'oublie tout tout de suite !
- ah bon ? et depuis quand ?
- depuis quand quoi ?

[Ghost-Raider]

calc et writer ont la même maladie mais ça dépend des gens et du moment.

Essais :
1 - j'ouvre sous OO mon fichier test qui ne pèse que 1012 kO.
soffice.bin est créé et pèse 167300 kO !
165 fois plus lourd !
je crée un fichier de vidage (DMP), il pèse 393116 kO.
J'ouvre ce fichier de vidage : il est "corrompu", plantage.

2 - J'ouvre mon fichier test sous LO
soffice.bin est créé : 590920 kO
584 fois plus lourd !
Je crée un fichier de vidage (DMP), il pèse 1249293 kO
J'ouvre ce fichier de vidage : il est "corrompu", plantage.

Pourquoi les fichiers soffice.bin sont-ils si gros ?
Pourquoi sont-ils bien plus gros sous LO que sous OO ?
Pourquoi les fichiers DMP sont-ils "corrompus" ?

Voilà, voilà...

[tTh]

On 10/10/23 19:42, Ghost-Raider wrote:

> Essais :
> 1 - j'ouvre sous OO mon  fichier test qui ne pèse que 1012 kO.
> soffice.bin est créé et pèse 167300 kO !

Qu'est-ce que tu veux dire par là précisément ?

--
+---------------------------------------------------------------------+
| https://wiki.interhacker.space/index.php?title=Techno-futilit%C3%A9 |
+---------------------------------------------------------------------+

[Alf92]

Ghost-Raider (le 10/10/2023 à 19:42:31) :

essaye de désactiver ou virer Java jre avant de lancer LO Calc pour voir

[Thierry HOUX]

Si je comprends bien comment ça fonctionne, soffice.bin est disons le
noyau de LO / OO. C'est lui qui est chargé, en fonction de ton choix de
travailler avec writer ou calc, de charger les modules correponsdants et
les libraires de dépendances.
La différence entre OO et LO est certainement due aux évolutions qui ont
eu lieu entre les deux suites.
Les fait que tu aient le même problème sur les deux provient d'une partie
historique commune aux deux suites. Si ce problème est identifié depuis
longtemps et pas encore traité est certainement du au fait de la
priorisation faite pour traiter les "bugs"; ce dernier devant être réputé
de fréquence "rare" sa priorité est basse.

DMP: Le plantage doit avoir lieu au moment ou il est écrit?

Bon, difficile d'aller plus loin, ça deviendrait de l'art devinatoire hors
de mon champ de compétences.

[pehache]

Le 10/10/2023 à 19:42, Ghost-Raider a écrit :
>
> Essais :
> 1 - j'ouvre sous OO mon fichier test qui ne pèse que 1012 kO.
> soffice.bin est créé et pèse 167300 kO !
> 165 fois plus lourd !
> je crée un fichier de vidage (DMP), il pèse 393116 kO.
> J'ouvre ce fichier de vidage : il est "corrompu", plantage.
>
> 2 - J'ouvre mon fichier test sous LO
> soffice.bin est créé : 590920 kO
> 584 fois plus lourd !
> Je crée un fichier de vidage (DMP), il pèse 1249293 kO
> J'ouvre ce fichier de vidage : il est "corrompu", plantage.
>
> Pourquoi les fichiers soffice.bin sont-ils si gros ?

Ce ne sont pas des fichiers, mais des process en mémoire. La taille d'un
process n'a pas forcément grand-chose à voir avec la taille d'un fichier
ouvert par ce process.

> Pourquoi sont-ils bien plus gros sous LO que sous OO ?

Seuls les développeurs des deux logiciels peuvent répondre. Par ailleurs
tu ne dis pas de quelle plateforme viennent ces chiffres, il est probable
que ce soit de Windows. Ca m'étonnerait que sur Linux soffice.bin soit si
gros dès l'ouverture (à moins que OO/LO soit installé par un flatpack
ou équivalent).

[Ghost-Raider]

Le 11/10/2023 à 11:51, pehache a écrit :
> Le 10/10/2023 à 19:42, Ghost-Raider a écrit :
>>
>> Essais :
>> 1 - j'ouvre sous OO mon fichier test qui ne pèse que 1012 kO.
>> soffice.bin est créé et pèse 167300 kO !
>> 165 fois plus lourd !
>> je crée un fichier de vidage (DMP), il pèse 393116 kO.
>> J'ouvre ce fichier de vidage : il est "corrompu", plantage.
>>
>> 2 - J'ouvre mon fichier test sous LO
>> soffice.bin est créé : 590920 kO
>> 584 fois plus lourd !
>> Je crée un fichier de vidage (DMP), il pèse 1249293 kO
>> J'ouvre ce fichier de vidage : il est "corrompu", plantage.
>>
>> Pourquoi les fichiers soffice.bin sont-ils si gros ?
>
> Ce ne sont pas des fichiers, mais des process en mémoire. La taille d'un
> process n'a pas forcément grand-chose à voir avec la taille d'un fichier
> ouvert par ce process.

OK. OK.

>
>> Pourquoi sont-ils bien plus gros sous LO que sous OO ?
>
> Seuls les développeurs des deux logiciels peuvent répondre. Par ailleurs
> tu ne dis pas de quelle plateforme viennent ces chiffres, il est probable
> que ce soit de Windows. Ca m'étonnerait que sur Linux soffice.bin soit si
> gros dès l'ouverture (à moins que OO/LO soit installé par un flatpack
> ou équivalent).

Effectivement, c'est sous Windows.
Voici l'occupation mémoire sous Linux avec mon fichier test de 1012 kO
seulement ouvert sous LO, je mets tout, tu t'y reconnaîtras.
commande : top -o %MEM
Soffice.bin est en premier. Il est gros comment ?
Si ce sont des octets,on a :
- sous Windows : 167300 kO
- sous Linux : 1179284 kO, 7 fois plus gros !


top - 19:19:31 up 7 min, 1 user, load average: 1,03, 0,51, 0,23
Tâches: 247 total, 1 en cours, 246 en veille, 0 arrêté, 0 zombie
%Cpu(s): 0,2 ut, 0,8 sy, 0,1 ni, 92,2 id, 6,7 wa, 0,0 hi, 0,0 si,
0,0 st
MiB Mem : 15835,1 total, 10994,7 libr, 1206,5 util, 3633,9 tamp/cache
MiB Éch: 2048,0 total, 2048,0 libr, 0,0 util. 14055,0 dispo Mem

PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+
COM.


1784 user 20 0 1179284 482896 135656 S 0,0 3,0 0:05.07
soffice.bin


1221 user 20 0 4322320 178704 105524 S 0,3 1,1 0:11.90
cinnamon


844 root 20 0 713120 114756 81248 S 1,3 0,7 0:12.44
Xorg


1601 user 20 0 736544 79608 49068 S 0,0 0,5 0:00.24
mintUpdate


1076 user 20 0 411524 76116 28364 S 0,0 0,5 0:00.76
csd-background


1701 user 20 0 784248 75696 49984 S 0,0 0,5 0:08.32
nemo


1252 user 20 0 1034972 66340 42252 S 0,0 0,4 0:01.08
nemo-desktop


901 user 20 0 580760 62452 47168 S 0,0 0,4 0:00.23
cinnamon-sessio


1256 user 20 0 644132 55016 43512 S 0,0 0,3 0:00.11
evolution-alarm


1669 user 20 0 405096 48700 30904 S 0,0 0,3 0:00.13
mintreport-tray


1261 user 20 0 399928 45192 36788 S 0,0 0,3 0:00.21
nm-applet


1820 user 20 0 469696 42400 31488 S 1,0 0,3 0:00.50
gnome-terminal-


1542 user 20 0 540172 41028 26868 S 0,0 0,3 0:00.09
blueberry-tray


1218 user 20 0 464056 37640 25064 S 0,0 0,2 0:00.08
cinnamon-launch


1250 user 20 0 316768 37232 25012 S 0,0 0,2 0:00.11
blueberry-obex-


1665 user 20 0 62628 35556 18972 S 0,0 0,2 0:00.10
applet.py


1160 user 20 0 556328 35432 29136 S 0,0 0,2 0:00.03
goa-daemon


1269 user 20 0 314352 34980 24660 S 0,0 0,2 0:00.09
cinnamon-killer


1101 user 20 0 527804 31272 24268 S 0,0 0,2 0:00.09
csd-power


1309 user 20 0 1251444 31088 26708 S 0,0 0,2 0:00.08
evolution-calen


1321 user 20 0 684540 29816 26296 S 0,0 0,2 0:00.04
evolution-addre


1064 user 20 0 310716 28072 21416 S 0,0 0,2 0:00.08
csd-print-notif


1725 user 20 0 456052 27916 22952 S 0,0 0,2 0:00.90
gvfsd-smb


1061 user 20 0 718196 27324 20880 S 0,0 0,2 0:00.09
csd-media-keys


1054 user 20 0 314740 27220 20416 S 0,0 0,2 0:00.07



1041 user 20 0 452160 26596 20248 S 0,0 0,2 0:00.08
csd-color


1087 user 20 0 304348 26444 19852 S 0,0 0,2 0:00.10
csd-xsettings


1050 user 20 0 381680 25972 19728 S 0,0 0,2 0:00.08
csd-sound


1286 user 20 0 393484 25808 22000 S 0,0 0,2 0:00.04
evolution-sourc


1532 root 20 0 89928 25732 22692 S 0,0 0,2 0:00.02
smbd


1036 user 20 0 302836 25528 19272 S 0,0 0,2 0:00.14
csd-keyboard


1086 user 20 0 377308 25508 19432 S 0,0 0,2 0:00.07
csd-xrandr


1048 user 20 0 376792 25188 19100 S 0,0 0,2 0:00.09
csd-automount


1096 user 20 0 302744 24720 18768 S 0,0 0,2 0:00.08
csd-mouse


1040 user 20 0 302776 24712 18792 S 0,0 0,2 0:00.08
csd-a11y-keyboa


1098 user 20 0 302788 24628 18548 S 0,0 0,2 0:00.12
csd-housekeepin


1077 user 20 0 302348 24600 18656 S 0,0 0,2 0:00.08
csd-screensaver


1072 user 20 0 302784 24560 18612 S 0,0 0,2 0:00.08
csd-a11y-settin


1062 user 20 0 450236 24500 18492 S 0,0 0,2 0:00.07
csd-orientation


1241 user 20 0 302520 24448 18604 S 0,0 0,2 0:00.05
xapp-sn-watcher


1085 user 20 0 228580 24444 18548 S 0,0 0,2 0:00.07
csd-clipboard


1047 user 20 0 228588 24168 18268 S 0,0 0,1 0:00.08
csd-cursor


1248 user 20 0 228336 23916 18128 S 0,0 0,1 0:00.04
polkit-gnome-au


1307 user 20 0 264632 23048 14164 S 0,0 0,1 0:00.07
cinnamon-slides


700 root 20 0 42236 20700 11992 S 0,0 0,1 0:00.08
networkd-dispat


690 root 20 0 339372 20272 17052 S 0,0 0,1 0:00.27
NetworkManager


1537 root 20 0 89216 20136 17264 S 0,0 0,1 0:00.01
samba-bgqd


900 user 9 -11 961456 19868 15040 S 0,0 0,1 0:00.07
pulseaudio


380 root 19 -1 68684 19104 17804 S 0,0 0,1 0:00.17
systemd-journal


1522 root 20 0 74284 16732 14428 S 0,0 0,1 0:00.01
nmbd


user@user:~$

Si je recopie deux fois sur elle-même une page de ce fichier qui en
contient 154, la première ligne augmente partout et passe à :
VIRT : 1589436
RES : 579824
SHR : 177552

On constate donc bien que soffice.bin est beaucoup plus gros sous Linux
que sous Windows.

--
Courrier envoyé par mon top super extra PC Hardware.fr sous Linux Mint
Cinnamon

[Ghost-Raider]

OK.

> La différence entre OO et LO est certainement due aux évolutions qui ont
> eu lieu entre les deux suites.

Oui. LO a été "amélioré" par rapport à OO.
Chez moi, je constate qu'il est moins fiable que OO, ce qui est reconnu
sur les sites où on les compare.

> Les fait que tu aient le même problème sur les deux provient d'une partie
> historique commune aux deux suites. Si ce problème est identifié depuis
> longtemps et pas encore traité est certainement du au fait de la
> priorisation faite pour traiter les "bugs"; ce dernier devant être réputé
> de fréquence "rare" sa priorité est basse.

C'est certainement vrai et ça me laisse peu d'espoir de correction.

Je connais d'autres bugs de LO ou OO, parfois communs, parfois non.
Ils n'ont pas été corrigés depuis des lustres mais ils sont
d’occurrences très rares.

>
> DMP: Le plantage doit avoir lieu au moment ou il est écrit?

Si j'essaye de le lire par un éditeur de texte, on me dit qu'il est
corrompu.

>
> Bon, difficile d'aller plus loin, ça deviendrait de l'art devinatoire hors
> de mon champ de compétences.
>

Et surtout du mien.

[tTh]

On 10/11/23 19:52, Ghost-Raider wrote:

>
> Si je recopie deux fois sur elle-même une page de ce fichier qui en
> contient 154, la première ligne augmente partout et passe à :
> VIRT : 1589436
> RES :    579824

Le VIRT c'est la mémoire virtuelle, elle est réservée, mais
n'existe pas toute en mémoire physique. Et le RES c'est la
partie résidente qui elle sera soit en ram soit dans le swap.

[Ghost-Raider]

Le 11/10/2023 à 20:38, tTh a écrit :
> On 10/11/23 19:52, Ghost-Raider wrote:
>
>>
>> Si je recopie deux fois sur elle-même une page de ce fichier qui en
>> contient 154, la première ligne augmente partout et passe à :
>> VIRT : 1589436
>> RES :    579824
>
> Le VIRT c'est la mémoire virtuelle, elle est réservée, mais
> n'existe pas toute en mémoire physique. Et le RES c'est la
> partie résidente qui elle sera soit en ram soit dans le swap.
>

Oui, j'avais compris ça et comme j'ai 16 GO de RAM, ça devrait passer.
Question : les chiffres ci-dessus sont en octets ou en kO ?

[Ghost-Raider]

Sauf erreur, je n'ai pas java jre sur mes PC.

[Alf92]

Ghost-Raider (le 11/10/2023 à 21:01:52) :

à vérifier qd même

dans la boite de dialogue "Options - LibreOffice - Avancé", sous
"Options Java", décocher "Utiliser un environnement d'exécution Java",
même si Java n'est pas installé.

[pehache]

Le 11/10/2023 à 19:52, Ghost-Raider a écrit :
>
> Si je recopie deux fois sur elle-même une page de ce fichier qui en
> contient 154, la première ligne augmente partout et passe à :
> VIRT : 1589436
> RES : 579824
> SHR : 177552

Ce qui compte c'est "RES", donc ici 580Mo. C'est beaucoup, certes, ce qui
ramène à...

> On constate donc bien que soffice.bin est beaucoup plus gros sous Linux
> que sous Windows.

..la question de savoir comment LO est installé sur ta distribution. La
mode est aux gestionnaires de paquets type flatpak ou snap: ça a l'air
pratique à première vue, mais un des inconvénients est une occupation
mémoire en général très supérieure à ce qu'elle est avec les
gestionnaire de paquets traditionnels sous Linux.

[Ghost-Raider]

Merci, en effet, Java jre est dans mes systèmes. Pourtant je me rappelle
avoir désinstallé plusieurs versions Windows, pas la dernière
apparemment et elle est aussi présente dans Linux.

Donc, essais de mon fichier test de 1 012 KO avec et sans java jre:

1 - LINUX/LO :
a) avec java, soffice.bin :
VIRT 1115 344
RES : 486 628
SHR : 138 704
b) sans java, soffice.bin :
VIRT 1180 208
RES : 486 812
SHR : 138 488
C'est pareil

2 - WINDOWS/LO
a) avec java, soffice.bin : 592 044
b) sans java, soffice.bin : 605 388
C'est pareil

3 - WINDOWS/OO
a) avec java, soffice.bin : 92 708
b) sans java, soffice.bin : 92 860

C'est pareil.

Java n'a pas d'incidence sur la taille des "fichiers"..

Mais on voit à nouveau que LO crée un soffice.bin bien plus gros qu'OO,
ce qui peut et même doit expliquer les plantages totaux de LO.

Et j'en reste à mon point de départ : faute de trouver une explication
rationnelle et un remède à ces plantages de LO, OO reste plus fiable,
tout en ne l'étant pas totalement, loin s'en faut.

Détails très amusants :

Si on explore la configuration avancée de LINUX/JAVA/LO, on trouve 106
lignes de préférences qui commencent toutes par org.openoffice...
Apparemment les développeurs qui ont traduit OO en LO sous LINUX ne se
sont pas cassé la tête.

Et si on explore la configuration avancée de WINDOWS/JAVA/LO, on trouve
également 106 lignes de préférences qui commencent toutes par
org.openoffice...

Donc les développeurs de LO sous Windows ne se sont pas non plus cassé
la tête.

[Ghost-Raider]

Je ne sais pas.
LO fait partie des logiciels pré-installés par LINUX Mint. Je n'y ai pas
touché.

[pehache]

Le 12/10/2023 à 16:24, Ghost-Raider a écrit :

> Java n'a pas d'incidence sur la taille des "fichiers"..
>
> Mais on voit à nouveau que LO crée un soffice.bin bien plus gros qu'OO,

Oui

> ce qui peut et même doit expliquer les plantages totaux de LO.

Très probablement pas. La taille n'est pas une raison de plantage en soi,
du moment qu'il y a toujours de la mémoire disponible.

>
> Si on explore la configuration avancée de LINUX/JAVA/LO, on trouve 106
> lignes de préférences qui commencent toutes par org.openoffice...
> Apparemment les développeurs qui ont traduit OO en LO sous LINUX ne se
> sont pas cassé la tête.

C'est le principe d'un fork : réutiliser le code source tel qu'il est. Et
aller modifier des noms d'objets qui pour l'essentiel sont invisibles
pour l'utilisateur lambda n'a que peu d'intérêt.

>
> Et si on explore la configuration avancée de WINDOWS/JAVA/LO, on trouve
> également 106 lignes de préférences qui commencent toutes par
> org.openoffice...
>
> Donc les développeurs de LO sous Windows ne se sont pas non plus cassé
> la tête.

Dans ce genre de logiciel, le code source pour les différents OS est
commun à 99%

[Ghost-Raider]

Le 12/10/2023 à 16:44, pehache a écrit :
> Le 12/10/2023 à 16:24, Ghost-Raider a écrit :
>
>> Java n'a pas d'incidence sur la taille des "fichiers"..
>>
>> Mais on voit à nouveau que LO crée un soffice.bin bien plus gros qu'OO,
>
> Oui
>
>> ce qui peut et même doit expliquer les plantages totaux de LO.
>
> Très probablement pas. La taille n'est pas une raison de plantage en soi,
> du moment qu'il y a toujours de la mémoire disponible.

Oui, mais en 32 bits, c'est je crois 1,6 GO, ce qui est compatible avec
les plantages vers 1,3 GO compte tenu des autres logiciels.
En 64 bits, je ne sais pas.
Les messages sur le web disent que la mémoire n'est jamais libérée, donc
soffice.bin gonfle, gonfle, gonfle,, GONFLE? *GONFLE* et PAF !

>>
>> Si on explore la configuration avancée de LINUX/JAVA/LO, on trouve 106
>> lignes de préférences qui commencent toutes par org.openoffice...
>> Apparemment les développeurs qui ont traduit OO en LO sous LINUX ne se
>> sont pas cassé la tête.
>
> C'est le principe d'un fork : réutiliser le code source tel qu'il est. Et
> aller modifier des noms d'objets qui pour l'essentiel sont invisibles
> pour l'utilisateur lambda n'a que peu d'intérêt.

Oui, bien sûr.

>
>>
>> Et si on explore la configuration avancée de WINDOWS/JAVA/LO, on trouve
>> également 106 lignes de préférences qui commencent toutes par
>> org.openoffice...
>>
>> Donc les développeurs de LO sous Windows ne se sont pas non plus cassé
>> la tête.
>
> Dans ce genre de logiciel, le code source pour les différents OS est
> commun à 99%

Et les erreurs de conception du départ aussi dont le fait que la mémoire
ne soit pas systématiquement libérée après un temps T.
Apparemment, ce n'est pas à l'ordre du jour et c'est regrettable pour
moi puisque LO est moins fiable que OO.
Il paraît qu'il y a une version Linux d'OO je vais regarder ce qu'il en
est mais j'ai horreur de passer mon temps en
essais/erreurs/corrections/essais/erreurs etc..et je ne souhaite pas
commencer à charger mon beau LINUX bien pur avec des trucs pas
catholiques qui foirent dans un autre système.

[pehache]

Le 12/10/2023 à 17:07, Ghost-Raider a écrit :
> Le 12/10/2023 à 16:44, pehache a écrit :
>> Le 12/10/2023 à 16:24, Ghost-Raider a écrit :
>>
>>> Java n'a pas d'incidence sur la taille des "fichiers"..
>>>
>>> Mais on voit à nouveau que LO crée un soffice.bin bien plus gros qu'OO,
>>
>> Oui
>>
>>> ce qui peut et même doit expliquer les plantages totaux de LO.
>>
>> Très probablement pas. La taille n'est pas une raison de plantage en soi,
>> du moment qu'il y a toujours de la mémoire disponible.
>
> Oui, mais en 32 bits, c'est je crois 1,6 GO,

Non

> ce qui est compatible avec
> les plantages vers 1,3 GO compte tenu des autres logiciels.
> En 64 bits, je ne sais pas.

Sur une distribution Linux 64 bits le LO installé de base est 64 aussi.
Et sous Windows je ne vois pas vraiment de raison d'installer une version
32 bits de LO alors qu'il est dispo en version 64 bits.

> Les messages sur le web disent que la mémoire n'est jamais libérée, donc
> soffice.bin gonfle, gonfle, gonfle,, GONFLE? *GONFLE* et PAF !

Je ne sais pas si soffice.bin libère la mémoire ou pas et gonfle ou pas,
ce que je dis c'est qu'il faudrait arriver à une taille bien plus grosse
que ça en mémoire pour que ça plante à cause de la taille. Il peut y
avoir plein d'autres raisons de plantages...

[Alf92]

Ghost-Raider (le 12/10/2023 à 16:24:46) :

> Merci, en effet, Java jre est dans mes systèmes. Pourtant je me rappelle
> avoir désinstallé plusieurs versions Windows, pas la dernière
> apparemment et elle est aussi présente dans Linux.

> (...)

> C'est pareil.
> Java n'a pas d'incidence sur la taille des "fichiers"..

ok

autres pistes à tenter :

désactiver "Enregistrer les informations de récupération"
c'est dans les options Chargement/Enregistrement

essayer avec d'autre version d'ODF (1, 1.1, 1.2, 1.2 étendu, 1.2
compatibilité)
c'est dans les options Chargement/Enregistrement

désactiver les modules linguistiques

[Alf92]

Alf92 (le 12/10/2023 à 18:11:07) :

et si non que dit le crash log ?
https://www.google.fr/search?q=libre+office+crash+log

[Ghost-Raider]

Le 12/10/2023 à 17:53, pehache a écrit :
> Le 12/10/2023 à 17:07, Ghost-Raider a écrit :
>> Le 12/10/2023 à 16:44, pehache a écrit :
>>> Le 12/10/2023 à 16:24, Ghost-Raider a écrit :
>>>
>>>> Java n'a pas d'incidence sur la taille des "fichiers"..
>>>>
>>>> Mais on voit à nouveau que LO crée un soffice.bin bien plus gros qu'OO,
>>>
>>> Oui
>>>
>>>> ce qui peut et même doit expliquer les plantages totaux de LO.
>>>
>>> Très probablement pas. La taille n'est pas une raison de plantage en soi,
>>> du moment qu'il y a toujours de la mémoire disponible.
>>
>> Oui, mais en 32 bits, c'est je crois 1,6 GO,
>
> Non

OK.

>
>> ce qui est compatible avec
>> les plantages vers 1,3 GO compte tenu des autres logiciels.
>> En 64 bits, je ne sais pas.
>
> Sur une distribution Linux 64 bits le LO installé de base est 64 aussi.
> Et sous Windows je ne vois pas vraiment de raison d'installer une version
> 32 bits de LO alors qu'il est dispo en version 64 bits.

Mon LO/Windows est bien en 64 bits.

>> Les messages sur le web disent que la mémoire n'est jamais libérée, donc

>> soffice.bin gonfle, goonfle, Goonfle, GOOONFLE, *GOOOONFLE* et PAF !

>
> Je ne sais pas si soffice.bin libère la mémoire ou pas et gonfle ou pas,

Ça, c'est constatable dans les processus,

> ce que je dis c'est qu'il faudrait arriver à une taille bien plus grosse
> que ça en mémoire pour que ça plante à cause de la taille. Il peut y
> avoir plein d'autres raisons de plantages...

C'est justement ce que je cherche, en pure perte je pense puisque depuis
des années, le problème persiste de version en version.
Tout ce que je sais c'est que quand soffice.bin atteint 1,3 GO, il explose.
La seule solution reconnue est de fermer le programme et là, soffice.bin
consent à se dégonfler.
C'est comme si ma voiture chauffait sans qu'on sache pourquoi.
Le mécano : - ben, M'sieur, c'est simple, vous vous arrêtez et vous
attendez qu'elle refroidisse...

[Christophe PEREZ]

Le Wed, 11 Oct 23 09:51:47 +0000, pehache a écrit :

>> Pourquoi les fichiers soffice.bin sont-ils si gros ?
>
> Ce ne sont pas des fichiers, mais des process en mémoire.

Il ne fait pas la distinction, le grand DSI de mes deux ?
:D :D

[GhostRider]

Et le processus que je t'ai demandé d'écrire, tu en es où ?
Tu veux de l'aide ?

[GhostRider]

Le 12/10/2023 à 18:19, Alf92 a écrit :
> Alf92 (le 12/10/2023 à 18:11:07) :
>> Ghost-Raider (le 12/10/2023 à 16:24:46) :
>>
>>> Merci, en effet, Java jre est dans mes systèmes. Pourtant je me rappelle
>>> avoir désinstallé plusieurs versions Windows, pas la dernière
>>> apparemment et elle est aussi présente dans Linux.
>>> (...)
>>> C'est pareil.
>>> Java n'a pas d'incidence sur la taille des "fichiers"..
>>
>> ok
>>
>> autres pistes à tenter :
>>
>> désactiver "Enregistrer les informations de récupération"
>> c'est dans les options Chargement/Enregistrement
>>
>> essayer avec d'autre version d'ODF (1, 1.1, 1.2, 1.2 étendu, 1.2
>> compatibilité)
>> c'est dans les options Chargement/Enregistrement

J'ai des vieilles version de fichiers Star Office, ça buguait déjà il y
a 20 ans.

>> désactiver les modules linguistiques

C'est vrai que LO/WRITER a beaucoup plus d'erreurs avec les changements
de langues et les correcteurs orthographiques que OO, mais bon...

>
> et si non que dit le crash log ?
> https://www.google.fr/search?q=libre+office+crash+log

Les fichiers crashlog sont vides.
Chez moi, les crash logs ne donnent jamais rien, et pour cause : le
système se plante et n'enregistre rien, c'est trop tard ! C'est du moins
comme ça que ça s'est toujours passé.

Mais je vais laisser tomber, j'y ai passé trop de temps en pure perte
car ce bug, vieux comme Mathusalem, en français ou en anglais, commun à
OO et à LO quel que soit le système : Linux ou Windows qui partagent
presque tout sauf les interfaces, mais qui est nettement plus grave chez
LO, hélas ! ne m'empêche pas de travailler puisque je suis prévenu et
que je mets la ceinture et les bretelles.

Il n'y a cependant aucun bug de cette nature dans EXCEL. Je viens de
faire l'essai avec mon fichier test, EXCEL ne consomme presque rien
comme ressources, ça fait réfléchir...

[pehache]

Le 12/10/2023 à 19:53, Ghost-Raider a écrit :
>>
>>> ce qui est compatible avec
>>> les plantages vers 1,3 GO compte tenu des autres logiciels.
>>> En 64 bits, je ne sais pas.
>>
>> Sur une distribution Linux 64 bits le LO installé de base est 64 aussi.
>> Et sous Windows je ne vois pas vraiment de raison d'installer une version
>> 32 bits de LO alors qu'il est dispo en version 64 bits.
>
> Mon LO/Windows est bien en 64 bits.

Donc ce n'est pas la taille en soi qui le fait planter, et la taille est
probablement un symptôme additionnel d'un autre problème, qui lui est
responsable des plantages.

[pehache]

Le 13/10/2023 à 13:29, GhostRider a écrit :

> Il n'y a cependant aucun bug de cette nature dans EXCEL. Je viens de
> faire l'essai avec mon fichier test, EXCEL ne consomme presque rien
> comme ressources, ça fait réfléchir...

Excel est sans aucun doute un excellent tableur et est (de loin) le
meilleur logiciel de Microsoft : efficace, stable, etc... PowerPoint est
assez moyen, et Word franchement pas terrible dès qu'on veut faire de la
mise en page qui ressemble à quelque chose avec des figures et cie (et
Word a eu sa période bugguée à mort, même si ça va bien mieux
maintenant).

[Alf92]

GhostRider (le 13/10/2023 à 13:29:34) :

> (...)

> Mais je vais laisser tomber, j'y ai passé trop de temps en pure perte
> car ce bug, vieux comme Mathusalem, en français ou en anglais, commun à
> OO et à LO quel que soit le système : Linux ou Windows qui partagent
> presque tout sauf les interfaces, mais qui est nettement plus grave chez
> LO, hélas ! ne m'empêche pas de travailler puisque je suis prévenu et
> que je mets la ceinture et les bretelles.
>
> Il n'y a cependant aucun bug de cette nature dans EXCEL. Je viens de
> faire l'essai avec mon fichier test, EXCEL ne consomme presque rien
> comme ressources, ça fait réfléchir...

=>
https://lecrabeinfo.net/installer-microsoft-office-word-excel-powerpoint-sur-linux.html

[GhostRider]

Dans le groupe photo, un participant qui est prof de maths à
l'université, tu dois le reconnaître, est bien d'avis qu'il faut avoir
la foi chevillée au corps pour résister à EXCEL à l'université et
qu'utiliser CALC est une preuve au mieux d'originalité militante.

POWERPOINT n'est pas extra en effet mais IMPRESS n'est pas beaucoup
mieux. J'ai fait des tas de présentations pour ma fille et ce logiciel
n'est pas très professionnel.

MS WORD n'est effectivement pas vraiment très bon et WRITER de LO ou AOO
est bien meilleur, en particulier, c'est vrai, pour l'inclusion d'images
ou d'objets. J'ai fait avec ma fille sa thèse de doctorat, plus de 600
pages, elle sous Writer/Libre Office sur son Mac Book Air et moi sous
Writer/AOO sur Windows 8. Nous n'avons jamais eu de problème
d'enregistrement / lecture réciproque et je n'ai noté que deux bugs,
très rares.
Le Premier, c'est la disparition fortuite des traits de séparation des
notes de bas de page sous Writer/LO/Mac transcrit sous
Writer/OO/Windows, mais pas l'inverse.
Le second, c'est l'insertion de sauts de pages parasites dans des
tableaux à l'italienne dont le texte d'une colonne comporte un
trait-d'union automatique de scission de mot.

J'ai signalé ces bugs mais sans résultat, on le comprend.

Pour le reste, Writer/LO ou OO est très bon et s'acoquine très bien avec
MS-Word qui est le logiciel le plus rencontré dans l'édition en sciences
humaines et d'ailleurs souvent assez mal utilisé par les secrétaires.

Il ressort de tout ceci que pour faire un travail donné, il faut choisir
le meilleur logiciel disponible sous le système d'exploitation qui
donnera les meilleurs résultats sans a priori.
C'est pour ça que j'ai deux PC sur mon bureau : un Linux et un Windows.

[GhostRider]

Une machine virtuelle ? Tu veux ma mort ! J'ai horreur des complications.
Mettre une machine virtuelle Windows sur un PC Linux alors que j'ai
justement un PC Windows juste à côté, ce serait du vice.
Et une photo de famille pour clore le fil :
https://www.cjoint.com/doc/23_10/MJnrONuNC64_IMG20220516183850-1.jpg

[Michel]

Le 13/10/2023 à 19:48, GhostRider a écrit :
>
> Une machine virtuelle ? Tu veux ma mort ! J'ai horreur des complications.
> Mettre une machine virtuelle Windows sur un PC Linux alors que j'ai
> justement un PC Windows juste à côté, ce serait du vice.
> Et une photo de famille pour clore le fil :
> https://www.cjoint.com/doc/23_10/MJnrONuNC64_IMG20220516183850-1.jpg
>

Si c'est réellement pour clore ce fil, MERCI !

[Christian Gaudin]

Le Fri, 13 Oct 2023 19:24:05 +0200, GhostRider a écrit :

> MS WORD n'est effectivement pas vraiment très bon et WRITER de LO ou AOO
> est bien meilleur, en particulier, c'est vrai, pour l'inclusion d'images
> ou d'objets. J'ai fait avec ma fille sa thèse de doctorat, plus de 600
> pages, elle sous Writer/Libre Office sur son Mac Book Air et moi sous
> Writer/AOO sur Windows 8.

tu vas me prendre pour un fétichiste, mais pourquoi ne pas parler de
LaTeX?

https://www.latex-project.org/

--
Christian

[Alf92]

GhostRider (le 13/10/2023 à 19:48:57) :

> Le 13/10/2023 à 14:43, Alf92 a écrit :

>> https://lecrabeinfo.net/installer-microsoft-office-word-excel-powerpoint-sur-linux.html
>
> Une machine virtuelle ? Tu veux ma mort ! J'ai horreur des complications.

non !
Wine + PlayOnLinux
"Pour installer Microsoft Office et utiliser les applications Word,
Excel et PowerPoint sur Linux, la solution consiste à utiliser Wine,
une couche de compatibilité qui permet d’exécuter des applications
Microsoft Windows natives sur d’autres systèmes d’exploitation comme
Linux, macOS ou BSD."

[Thierry HOUX]

Certes LaTeX est certainement ce qui se fait de mieux pour éditer un livre
en terme de résultat, très professionnel, mais à éditer c'est un langage
de balises, et même s'il y a des éditeurs quasi wysiwyg comme LyX il
demande un temps significatif pour s'y familiariser.

[GhostRider]

Merci de le mentionner.

On trouve dans l'article de Wikipedia toutes les raisons pour lesquelles
LaTeX ne semble pas utilisé en sciences humaines.
https://fr.wikipedia.org/wiki/LaTeX
Ma fille a reçu une formation à LaTeX mais ne l'a jamais utilisé, de
même pour ses collègues. A part sa thèse de sociologie, elle a publié
une douzaines d'articles, toujours créés avec le traitement de texte du
moment. Le dernier, en cours de publication par une revue de sociologie
à comité de lecture de Routledge a donné lieu, comme les autres, à de
très nombreux échanges, tous plus anti-LaTeX que possible : versions de
Word obsolètes dans un sens, polices et structure à vau-l'eau, PDF
commentés en dur en retour, remarques par courriels, corrections de
dernière minute finalement re-corrigées et re-re-corrigées, puis
supprimées etc... Rien de structuré, ce sont des idées et des textes
jetés sur le papier, aux secrétaires de faire le ménage.

J'ai eu beaucoup de travail avec les 600 pages de la thèse de ma fille
car elle comprend de nombreux passages en plusieurs langues, dont
particulièrement l'indonésien, dont les règles typographiques différent
du français et même l’orthographe indonésienne n'est souvent pas fixée
et peut différer dans un même document, ce qui ne semble gêner personne
sauf les cartésiens que nous sommes.

L'avantage principal que je verrais à LaTeX dans une thèse de sciences
humaines serait la constitution automatique de la table des matières
finale avec les hyperliens. Avec un traitement de texte actuel, ça se
fait tout seul si on respecte la hiérarchie des titres, sous-titres
etc.. et il est très facile de modifier cette hiérarchie en changeant
leur niveau : Titre 1, Titre 2, Titre 3 etc...
En revanche, la bibliographie est particulièrement pénible car elle doit
suivre des règles typographiques précises alors que les citations de
œuvres ne la suivent souvent pas. Il faut tout corriger, ordonner et
contrôler à la main des dizaines de références. Rien que les noms des
auteurs sont problématiques car souvent, on ne distingue pas le nom
du/des prénoms ou bien ils contiennent des caractères latins non
courants, comme en polonais, en danois...

Voilà, voilà...

[Christian Gaudin]

Pour une thèse de doctorat qui représente un travail sur 3 ou 4 ans et un
document de plus 600 pages, ça vaut peut-être le coup de consacrer
quelques dizaines d'heures à maîtriser Latex.

J'imagine qu'avec un document de 600 pages sous Word, il doit bien y avoir
quelques dizaines d'heures perdues en mise en page si on n'a pas pris soin
de bien structurer (baliser?) son document et d'utiliser des feuilles de
styles, sans parler des notes de bas de page qui se déplacent avec les
sauts de page et autres joyeusetés.

--
Christian

[GhostRider]

Oui, je sais, je sais... mais j'ai deux PC, l'un sous Linux, l'autre
sous Windows, reliés par Samba. Je peux travailler sur les fichiers de
l'un à partir de l'autre. Ça ne pose pas de problèmes sauf que bien sûr
les fichiers sont bloqués en écriture par le PC qui les modifie.
Donc je n'ai pas besoin d'une machine virtuelle ou assimilée.
Effectivement, si je lâchais Windows et que je passais en Linux sur les
deux PC, le problème se poserait, mais ce n'est pas à l'ordre du jour.

[GhostRider]

Il est toujours regrettable de devoir terminer un fil par un constat
d'échec.
La prochaine fois, peut-être pourras-tu apporter un avis ou une expérience ?

[GhostRider]

Le 14/10/2023 à 11:27, Christian Gaudin a écrit :
> Le 14 Oct 2023 03:23:05 GMT, Thierry HOUX a écrit :
>
>> Le 13 Oct 2023 20:14:34 GMT, Christian Gaudin a écrit :
>>
>>> Le Fri, 13 Oct 2023 19:24:05 +0200, GhostRider a écrit :
>>>
>>>> MS WORD n'est effectivement pas vraiment très bon et WRITER de LO ou
>>>> AOO est bien meilleur, en particulier, c'est vrai, pour l'inclusion
>>>> d'images ou d'objets. J'ai fait avec ma fille sa thèse de doctorat,
>>>> plus de 600 pages, elle sous Writer/Libre Office sur son Mac Book Air
>>>> et moi sous Writer/AOO sur Windows 8.
>>>
>>> tu vas me prendre pour un fétichiste, mais pourquoi ne pas parler de
>>> LaTeX?
>>>
>>> https://www.latex-project.org/
>>
>> Certes LaTeX est certainement ce qui se fait de mieux pour éditer un
>> livre en terme de résultat, très professionnel, mais à éditer c'est un
>> langage de balises, et même s'il y a des éditeurs quasi wysiwyg comme
>> LyX il demande un temps significatif pour s'y familiariser.
>
> Pour une thèse de doctorat qui représente un travail sur 3 ou 4 ans et un
> document de plus 600 pages, ça vaut peut-être le coup de consacrer
> quelques dizaines d'heures à maîtriser Latex.

La thèse de ma fille s'est étendue sur bien plus de 3 ou 4 ans de
calendrier en raison de ses nombreuses autres activités : contrats de
monitorat, d'ATER, de chargée de cours, remplacements, séminaires,
voyages, longs séjours en Indonésie et dans tout le Sud-est asiatique,
aux USA, en Hollande, assimilation de la langue, étude des religions,
des régimes politiques, de la législation (hybride: coloniale/locale),
articles etc..
Le sujet lui-même a été revu, modifié, amplifié, réduit en fonction du
travail, c'est une thèse de recherche dont l'objet se découvre et même
se crée en avançant.

>
> J'imagine qu'avec un document de 600 pages sous Word, il doit bien y avoir
> quelques dizaines d'heures perdues en mise en page si on n'a pas pris soin
> de bien structurer (baliser?) son document et d'utiliser des feuilles de
> styles, sans parler des notes de bas de page qui se déplacent avec les
> sauts de page et autres joyeusetés.

En fait, une fois définies quelques grandes parties, la structure n'est
pas bien fixe, elle est même assez variable selon l'avancement du
travail et telle ou telle partie en cours d'écriture devient une
sous-partie plus loin selon l'importance ou le rôle qu'on veut lui
donner. Ça m'a posé quelques problèmes, c'est vrai, mais surtout
d'homogénéisation avec ce qui précède et ce qui suit. Parfois il faut
récrire plusieurs pages pour éviter les redites.

Le style ne pose pas de problème : Times New Roman 12, français ou autre
langue, ce qui modifie automatiquement la typographie : guillemets,
espaces etc.. et vérifie l'orthographe de la langue utilisée. Il faut
compléter les dictionnaires au fil de l'eau.
Les renvois de bas de page ne posent pas non plus de problèmes, ils se
déplacent et se renumérotent si on déplace du texte.

Pour conclure définitivement, puisque c'était l'objet des remarques
initiales concernant LaTeX, OO fait tout cela très bien et même un peu
mieux que LO.

[Michel]

Sous linux, probablement, mais sûrement pas pour windows, que tu cites
sans cesse ici, sur un forum dédié à linux.

[pehache]

Le 13/10/2023 à 19:24, GhostRider a écrit :
> Le 13/10/2023 à 14:16, pehache a écrit :
>> Le 13/10/2023 à 13:29, GhostRider a écrit :
>>
>>> Il n'y a cependant aucun bug de cette nature dans EXCEL. Je viens de
>>> faire l'essai avec mon fichier test, EXCEL ne consomme presque rien
>>> comme ressources, ça fait réfléchir...
>>
>> Excel est sans aucun doute un excellent tableur et est (de loin) le
>> meilleur logiciel de Microsoft : efficace, stable, etc... PowerPoint est
>> assez moyen, et Word franchement pas terrible dès qu'on veut faire de la
>> mise en page qui ressemble à quelque chose avec des figures et cie (et
>> Word a eu sa période bugguée à mort, même si ça va bien mieux
>> maintenant).
>>
> Dans le groupe photo, un participant qui est prof de maths à
> l'université, tu dois le reconnaître, est bien d'avis qu'il faut avoir
> la foi chevillée au corps pour résister à EXCEL à l'université et
> qu'utiliser CALC est une preuve au mieux d'originalité militante.

A titre personnel j'utilise LO calc, mais je ne fais en général rien de
bien complexe avec (ou plutôt, je ne gère pas des feuilles de calcul à
la fois grosses et complexes). Je pense que dans le milieu éducatif ça
convient très bien. Par contre j'ai pu en voir les limites, genre
feuilles de calcul qui le font mouliner avec peine, là où Excel s'en
sort facilement. Si j'avais besoin, je n'hésiterais pas un instant à
utiliser Excel (qui a par ailleurs quelques fonctions avancées qu'on ne
trouve pas dans calc).

>
> MS WORD n'est effectivement pas vraiment très bon et WRITER de LO ou AOO
> est bien meilleur, en particulier, c'est vrai, pour l'inclusion d'images
> ou d'objets.

Ni l'un ni l'autre ne conviennent pour les gros documents scientifiques
avec des nombreuses illustration : le placement automatique des figures
n'est pas adapté du tout et il faut passer son temps à reprendre les
mise en page à la main, ou accepter d'avoir des trous partout.

[GhostRider]

Désolé, mais le problème de fuite de mémoire concerne à la fois LO et OO
sous les deux systèmes, Windows et Linux, je l'ai bien mis en évidence.
Il ne faut pas se voiler la face et faire comme si Linux était seul au
monde, c'est en le comparant à Windows au cas par cas qu'on peut
l'améliorer.
Pour ma part, j'ai les deux et j'utilise le système le plus adéquat pour
ce que j'ai à faire.
Par exemple, une de mes clés USB semblait HS sous Windows. Linux l'a
reformatée correctement. C'est pareil pour effacer un fichier
récalcitrant, Linux est bien meilleur.
Mais inversement, l'aperçu des fichiers dans l'explorateur est meilleur
dans Windows.
Que les programmeurs de Linux l'améliorent, c'est tout ce que je souhaite.

Bien entendu, si j'ai un problème strictement Windows, je n'en parlerai
pas ici, ni sur un forum Windows pour parler d'un problème Linux.

[GhostRider]

Je constate finalement avec un grand regret que CALC, que ce soit sous
OO ou LO, et que ce soit sous Windows ou sous Linux, comporte un bug de
fuite de mémoire qui rend le travail sur mes gros fichiers aléatoire
avec risque de pertes.

Aucune des sommités de céans n'ayant pu apporter la moindre solution, ce
bug ancien étant structurel et non conjoncturel, à mon grand regret je
vais donc basculer mes gros tableaux comptables sur EXCEL, et ça marche
très bien sans bug.

Au cas ou MS découvrirait que j'ai une version dépassée d'EXCEL tombée
du camion, crime abominable, et s'arrangerait pour saboter mon EXCEL à
l'occasion d'une mise à jour, j'aurai toujours la solution de rebasculer
sur OO.

Voilà, voilà...

>> MS WORD n'est effectivement pas vraiment très bon et WRITER de LO ou AOO
>> est bien meilleur, en particulier, c'est vrai, pour l'inclusion d'images
>> ou d'objets.
>
> Ni l'un ni l'autre ne conviennent pour les gros documents scientifiques
> avec des nombreuses illustration : le placement automatique des figures
> n'est pas adapté du tout et il faut passer son temps à reprendre les
> mise en page à la main, ou accepter d'avoir des trous partout.
>

Pour l'instant, je garde OO/Writer puisque ma fille l'utilise aussi et
qu'il fonctionne bien. IMPRESS aussi, tout n'est donc pas perdu pour le
logiciel libre !

[Philippe Weill]

Le 13/10/2023 à 19:48, GhostRider a écrit :

> Le 13/10/2023 à 14:43, Alf92 a écrit :
>> GhostRider (le 13/10/2023 à 13:29:34) :
>>
>>> (...)
>>> Mais je vais laisser tomber, j'y ai passé trop de temps en pure perte
>>> car ce bug, vieux comme Mathusalem, en français ou en anglais, commun à
>>> OO et à LO quel que soit le système : Linux ou Windows qui partagent
>>> presque tout sauf les interfaces, mais qui est nettement plus grave chez
>>> LO, hélas ! ne m'empêche pas de travailler puisque je suis prévenu et
>>> que je mets la ceinture et les bretelles.
>>>

As tu déja fait des essais de ton fichier excel avec onlyoffice (desktop) ?

[GhostRider]

Heu... non, je ne connaissais pas trop, merci.

Sitôt lu, sitôt installé avec mon fichier test en format ODS (format OO
ou LO).
L'interface à l'air très bien, très claire avec un onglet "Collaboration".
Les commandes sont très similaires, on est en terrain connu.

Mon fichier test ODS s'affiche sans défaut, les formules sont là.
L'occupation mémoire varie pas mal et se stabilise à environ 300 MO ce
qui n'est pas rien.

Selon mon protocole de test d'occupation mémoire, je recopie un des 154
tableaux sur lui-même, l'occupation mémoire se stabilise à 500 MO
environ. Je refais la même opération 2 fois de suite, l'occupation
mémoire se stabilise à 600 MO environ.
J'annule ces 3 recopies, l'occupation mémoire passe à 700 MO !
Aïe !
Ça ressemble fort au comportement de LO/OO qui ne libèrent pas la
mémoire inutilisée.
Bon, ce n'est qu'un premier essai avec un fichier ODS.

Je refais la même opération dans OnlyOffice avec le même fichier test en
format XLS.
L'occupation mémoire est de 33 MO, à comparer à 300 MO en ODS.
Je refais l'opération de copie, l'occupation mémoire passe à 35 MO.
Je refais la même opération 2 fois de suite, l'occupation mémoire passe
à 38,5 MO seulement.
J'annule ces 3 recopies, l'occupation mémoire revient à 38 MO.

On voit ainsi qu'en format ODS, l'occupation mémoire est initialement 10
fois plus importante qu'en format XLS et atteint jusqu'à 20 fois en cas
d'opérations simples sur le fichier, sans être ensuite réduite.

Ce sont les mêmes résultats que quand on compare EXCEL avec OO ou LO.

Et donc, en réalité, ce ne sont pas les logiciels OO ou LO qui sont en
cause dans la fuite mémoire, c'est bien plus grave !

C'est la structure même de la base de données qui est défectueuse.

Et on comprend pourquoi personne n'a jamais corrigé ce bug. C'est la
base de données datant de StarOffice qui devrait être réécrite et tout
le reste avec.

Conclusion : OO et LO souffrent d'un mal congénital impossible à guérir.

RIP LO !