bonjour
je parlais de rapidité à adef dans le fil parallèle. il y a des choix à respecter et l'essentiel est
a/ le nombre de lecteurs disponibles
b/ la capacité du RAM
en effet, c'est le calvaire quand puppy bloque le CD et ne le rend pas, parce qu'il en a constamment besoin lui-même, parce que le PC n'a pas trop de RAM, car, alors, ton lecteur/graveur est bloqué pour de bon...
par contre, si tu as beaucoup de RAM, tu peux faire exécuter très vite des bibliothèques considérables de programmes utiles...
... mais ceux au prix d'une réelle lenteur au démarrage.
nous avons 2 PC principaux.
- mon laptop MEDION qui a 256 Moctets de RAM seulement
- le PC mini DELL SX270 de ma femme qui lui, a 512 Moctets de RAM
tous les 2 n'ont qu'un seul lecteur/graveur de CD / DVD
sous puppy, mon laptop fait du bruit: les souffleries de refroidissement fonctionnent en permanence (pas du tout sous windows), donc je ne le lance que qu'en j'en ai besoin. en outre, j'ai remarqué que si je regrave ma version de puppy, c'est vers 118 .. 122 Moctets que puppy ne veut plus me restituer le CD: je n'ai plus assez de RAM pour que puppy tourne intégralement dans le RAM. vu que la mémoire VIDEO en consomme pas mal sans doute. par contre, il charge ces 118 Moctets en quelque chose comme 2 minutes
sous puppy sur le DELL de ma femme, on n'entend rien (passée la bruyante phase de démarrage). l'ordi est en marche toute la journée de 8 h 00 à 23 h, est connu pour parait-il consommer peu de courant, et on ne monte puppy qu'une fois par jour et n'arrête jamais. et là on monte une vraie tapée de beaux programmes d'un coup, 280 Moctets. grâce au 512 Moctets de RAM, tout tourne en RAM (toute la journée!) et puppy restitue encore le CD, donc le lecteur est libre toute la journée pour autre chose. par contre charger ces 280 Moctets demande presque 6 minutes! on ne le ferait pas tous les quarts d'heure!
l'avantage des programmes sur disque "remastered" sont qu'ils sont directement dans le RAM de but en blanc, avec l'incomparable vitesse d'exécution, inégalée même par les meilleures des autres distributions de linux ou de windows!
mais si on encombre inutilement sa version "remastered", à un moment, le ram devient insuffisant, et donc puppy travaille avec lent lecteur de CD (au lieu du rapide disque dur), et ne rend plus le CD...
on a alors une trotinette
il faut trouver l'équilibre entre ce que l'on met dans la version remastered et ce que l'on mémorise dans le fichier de puppy sur le disque dur (qui est considérablement plus rapide que le CD!)
j'ai remarqué que Open Office est très rapide même en restant sur le disque dur. heureusement, car c'est un redoutable gros morceau!
si on veut donc un Open Office en RAM, on devrait opter de préférence pour l'une des 4 versions allégées contenant Open Office de but en blanc. le tout fait autour des 100 .. 120 Moctets et même sur mon laptop limité, le CD est restitué, c.a.d. que tout tourne en RAM, donc Open Office aussi. mais ces versions allégées ont Xvesa et non pas Xorg, comme nous francophones devrions préférer.
bon, il y a donc des choix à faire...
salut
tactique de rapidité
7 ans plus tard... 2014
L'histoire va montrer que beaucoup vont vouloir charger ce petit étalon pendant que d'autres chercheront à alléger leur percheron (Debian)
Bonjour,
Il est totalement faux de dire qu'avec 256Mo de ram Open Office soit chargé en ram
À lui seul Le sfs de d'Open Office (ou Libre Office...) allégé fait au alentour de 150Mo soit décompressé/monté trois fois plus : ~450Mo
Idem en chargeant Puppy en ram, suivant la version, le sfs principal fait de 120 à 160 Mo
Et avec des sfs compressés en xz c'est plus de quatre fois la taille après décompression...
Donc Puppy + Open Office ça fait minimum 1 Go décompressé en ram sans compter qu'il faut naturellement encore suffisamment de ram pour faire tourner le système et pouvoir lancer les applications
C'est pour cela qu'avec 256Mo de ram l'on entend parler depuis longtemps de la barrière des 100 Mo pour l'image iso (sfs principal compressé en gz)
Au delà forcement il est impossible de libérer le lecteur CD/DVD, donc se tourner sur une installation frugale ou complète mais bien sûr ce sera alors le support usb/dd qui ne pourra pas non plus être retiré
Cordialement,
Médor.
Il est totalement faux de dire qu'avec 256Mo de ram Open Office soit chargé en ram
À lui seul Le sfs de d'Open Office (ou Libre Office...) allégé fait au alentour de 150Mo soit décompressé/monté trois fois plus : ~450Mo
Idem en chargeant Puppy en ram, suivant la version, le sfs principal fait de 120 à 160 Mo
Et avec des sfs compressés en xz c'est plus de quatre fois la taille après décompression...
Donc Puppy + Open Office ça fait minimum 1 Go décompressé en ram sans compter qu'il faut naturellement encore suffisamment de ram pour faire tourner le système et pouvoir lancer les applications
C'est pour cela qu'avec 256Mo de ram l'on entend parler depuis longtemps de la barrière des 100 Mo pour l'image iso (sfs principal compressé en gz)
Au delà forcement il est impossible de libérer le lecteur CD/DVD, donc se tourner sur une installation frugale ou complète mais bien sûr ce sera alors le support usb/dd qui ne pourra pas non plus être retiré
Cordialement,
Médor.
ah oui? tu veux que je te monte un ISO de Puppy en ligne qui ne fait que 99 MB OO inclus ?
naturellement pas le plus moderne mais un vieux Puppy, selon le motto, «petit deviendra grand» mais il a le mérite d'être là et de fonctionner! car un vieux OO vaut bien un Gnome-Office dit moderne mais toujours sous développé par rapport à Star Office 5.1 (la dernière version de la sté StarOffice initiale et qui fut mise, avec la précédente 5.0, sous Public Domain. OO débutant était à peu près équivalent, sauf que le navigateur et bureau intégrés y ont été, de toute évidence définitivement, supprimés!). Et aujourd'hui encore je préfèrerais toujours ces vieux Puppy 1.8 et 2.0 avec OO intégré s'ils pouvaient traiter l'USB, notamment les claviers etc., correctement (celà ne fut le cas qu'à partir de Puppy 2.10. et, surtout, 2.12, sur lequel se basent plusieurs légendaires remasteurisations).
regarde la date du message!
Pelo s'em....... à 100 sous de l'heure à la retraite et est en train de déterrer des de vraies antiquités: le 19.2.2007, c'était 4 ans après le démarrage de Puppy et de ce forum... aujourd'hui, nous sommes 10 ans après ce démarrage, 6 ans plus tard, bien tassés, que ce message...
ding - ding - ding, réveillez vous les gars
naturellement pas le plus moderne mais un vieux Puppy, selon le motto, «petit deviendra grand» mais il a le mérite d'être là et de fonctionner! car un vieux OO vaut bien un Gnome-Office dit moderne mais toujours sous développé par rapport à Star Office 5.1 (la dernière version de la sté StarOffice initiale et qui fut mise, avec la précédente 5.0, sous Public Domain. OO débutant était à peu près équivalent, sauf que le navigateur et bureau intégrés y ont été, de toute évidence définitivement, supprimés!). Et aujourd'hui encore je préfèrerais toujours ces vieux Puppy 1.8 et 2.0 avec OO intégré s'ils pouvaient traiter l'USB, notamment les claviers etc., correctement (celà ne fut le cas qu'à partir de Puppy 2.10. et, surtout, 2.12, sur lequel se basent plusieurs légendaires remasteurisations).
regarde la date du message!
Pelo s'em....... à 100 sous de l'heure à la retraite et est en train de déterrer des de vraies antiquités: le 19.2.2007, c'était 4 ans après le démarrage de Puppy et de ce forum... aujourd'hui, nous sommes 10 ans après ce démarrage, 6 ans plus tard, bien tassés, que ce message...
ding - ding - ding, réveillez vous les gars
Bonjour Oui,
Effectivement j'ai bien vu la date mais après avoir répondu
Ce qui ne remet pas ma réponse en cause car pour pouvoir travailler tout en ram il faut que les fichiers et le système tiennent dans la ram
Si tu prends l'exemple de l'iso de Slitaz 3 ordinaire elle pèse 30 Mo, la version lowram fait 120 Mo !
Dans mes vieilleries j'ai toujours Star Office 5.1 qui d'ailleurs à l'origine était produit par la société allemande StarDivision avant son rachat par Sun
Malheureusement Pelo a la capacité de mettre le souk sur le forum à défaut d'être apte à suivre des cours d'informatique
Cordialement,
Médor.
Effectivement j'ai bien vu la date mais après avoir répondu
Ce qui ne remet pas ma réponse en cause car pour pouvoir travailler tout en ram il faut que les fichiers et le système tiennent dans la ram
Si tu prends l'exemple de l'iso de Slitaz 3 ordinaire elle pèse 30 Mo, la version lowram fait 120 Mo !
Dans mes vieilleries j'ai toujours Star Office 5.1 qui d'ailleurs à l'origine était produit par la société allemande StarDivision avant son rachat par Sun
Malheureusement Pelo a la capacité de mettre le souk sur le forum à défaut d'être apte à suivre des cours d'informatique
Cordialement,
Médor.
bonjour Médor
bonne réponse. merci!
j'en reviens au premier message que Pelo a donc déterré! il y a une explication: j'ai toujours donné énormément de place à ma SWAP, et dès qu'il y une SWAP, Linux s'en accapare toujours.
comment Linux gère la SWAP, ce n'est sans doute un secret pour personne, puisque Linux est Open Source, mais c'est quand même resté un secret pour moi. je suppose seulement que c'est l'explication: dans mes 2 Go de SWAP que je donnais déjà à l'époque, on peut même loger un Debian graphique actuel, et pas seulement le live d'Emil... est-ce que Puppy, ou son Linux (Slackware à l'époque) l'a fait, je l'ignore! Mais comme Puppy restituait le CD et que j'avais besoin du lecteur pour d'autres choses (en 2007, je pense que je n'avais peut-être encore jamais possédé de clef USB), d'une part, et que d'autre part tout marchait, je ne me suis jamais posé la question.
le squashing à très haut taux de compression est d'ailleurs plus récent, même si c'est pas tout neuf! pour SliTaz, c'est absolument essentiel: sinon on se serait rendu compte que SliTaz aussi a terriblement engraissé (changé d'équipement, presque plus rien dedans, et mis des programmes légers-légers, de manière extrêmement habile d'ailleurs, la gestion de l'installeur et le gestionnaire de paquets la version adaptée de Midori, c'est tout bonnement génial, avec l'avantage en plus, que Midori fonctionne vraiment, car les gars de SliTaz on creuvé l'abcès et fait de Midori un navi sans concession...
...dans SliTaz, alors que dans d'autres distros, on a souvent des ratées avec.
dans ses receptes sur le forum de Puppy, Dougal préconisait longtemps (je ne sais d'ailleurs pas s'il a changé - je me limite simplement à ne pas prétendre qu'il le préconise à la date actuelle) le squashing basse compression, et SliTaz 1 et 2, c'était encore mieux, c'était à très basse compression (j'obtenais des facteurs de décompression de juste un peu plus de 1,5!). ceux qui ont encore le manuel initial de Christophe, d'ailleurs, peuvent le lire clairement dans SliTaz from Scratch (la recepte initiale, car elle aussi a changé.
les développeurs n'aiment d'ailleurs le recours à la très haute compression qu'en tout dernier recours, car cela les fait poireauter devant leur écrans très longtemps en plus pour des clopinettes, et, à la décompression, cela aussi mange considérablement du temps (mais quand le fichier n'est pas sur un support rapide, j'appelle support rapide un disque dur 7200 rpm, cela peut être modéré légèrement par le gain de temps de lecture du contenu de l'ISO en RAM). ce sont des considérations difficiles et à apprécier et à généraliser dans le monde de Puppy, dont les adeptes disposent d'une variété considérable de hardware les plus diverses... l'un se fiche de gains minimes alors que pour l'autre, toujours rivé pas les circonstances à une trottinette, ils peuvent être quand même très intéressants. j'ai eu des phase par ex. de PC d'occas n'ayant au départ que 10 GB de disque dur à 5400 upm avant de trouver un disque de rechange... il y en a qui ont gardé cela, car ils n'ont jamais acheté de l'occas, le PC neuf leur a coûté, à l'époque, la peau des fesses, et ils ont considéré que c'était comme le mariage, un contrat pour le reste de la vie...
bonne réponse. merci!
j'en reviens au premier message que Pelo a donc déterré! il y a une explication: j'ai toujours donné énormément de place à ma SWAP, et dès qu'il y une SWAP, Linux s'en accapare toujours.
comment Linux gère la SWAP, ce n'est sans doute un secret pour personne, puisque Linux est Open Source, mais c'est quand même resté un secret pour moi. je suppose seulement que c'est l'explication: dans mes 2 Go de SWAP que je donnais déjà à l'époque, on peut même loger un Debian graphique actuel, et pas seulement le live d'Emil... est-ce que Puppy, ou son Linux (Slackware à l'époque) l'a fait, je l'ignore! Mais comme Puppy restituait le CD et que j'avais besoin du lecteur pour d'autres choses (en 2007, je pense que je n'avais peut-être encore jamais possédé de clef USB), d'une part, et que d'autre part tout marchait, je ne me suis jamais posé la question.
le squashing à très haut taux de compression est d'ailleurs plus récent, même si c'est pas tout neuf! pour SliTaz, c'est absolument essentiel: sinon on se serait rendu compte que SliTaz aussi a terriblement engraissé (changé d'équipement, presque plus rien dedans, et mis des programmes légers-légers, de manière extrêmement habile d'ailleurs, la gestion de l'installeur et le gestionnaire de paquets la version adaptée de Midori, c'est tout bonnement génial, avec l'avantage en plus, que Midori fonctionne vraiment, car les gars de SliTaz on creuvé l'abcès et fait de Midori un navi sans concession...
...dans SliTaz, alors que dans d'autres distros, on a souvent des ratées avec.
dans ses receptes sur le forum de Puppy, Dougal préconisait longtemps (je ne sais d'ailleurs pas s'il a changé - je me limite simplement à ne pas prétendre qu'il le préconise à la date actuelle) le squashing basse compression, et SliTaz 1 et 2, c'était encore mieux, c'était à très basse compression (j'obtenais des facteurs de décompression de juste un peu plus de 1,5!). ceux qui ont encore le manuel initial de Christophe, d'ailleurs, peuvent le lire clairement dans SliTaz from Scratch (la recepte initiale, car elle aussi a changé.
les développeurs n'aiment d'ailleurs le recours à la très haute compression qu'en tout dernier recours, car cela les fait poireauter devant leur écrans très longtemps en plus pour des clopinettes, et, à la décompression, cela aussi mange considérablement du temps (mais quand le fichier n'est pas sur un support rapide, j'appelle support rapide un disque dur 7200 rpm, cela peut être modéré légèrement par le gain de temps de lecture du contenu de l'ISO en RAM). ce sont des considérations difficiles et à apprécier et à généraliser dans le monde de Puppy, dont les adeptes disposent d'une variété considérable de hardware les plus diverses... l'un se fiche de gains minimes alors que pour l'autre, toujours rivé pas les circonstances à une trottinette, ils peuvent être quand même très intéressants. j'ai eu des phase par ex. de PC d'occas n'ayant au départ que 10 GB de disque dur à 5400 upm avant de trouver un disque de rechange... il y en a qui ont gardé cela, car ils n'ont jamais acheté de l'occas, le PC neuf leur a coûté, à l'époque, la peau des fesses, et ils ont considéré que c'était comme le mariage, un contrat pour le reste de la vie...
Re,
Bien sûr avec une swap ça aide ! Mais en fait Puppy ne décompresse pas tout en ram si elle n'est pas suffisante.
J'ai actuellement avec Slacko-5.7.0 en frugale et 256 Mo de ram dont 12 Mo partagés :
L'occupation en mémoire est de : 153/239 Mo
Mon fichier de swap affiche : 498/500 Mo, soit 2 Mo d'occupés actuellement.
Et j'ai Opera, Sakura et Leafpad qui tournent en plus de X, Openbox, Lxpanel, Gkrellm
Pour en revenir à Slitaz v3.0, le cd loram fait 132 Mo contre 32 Mo pour l'iso classique...
Voir sur cette page le détail, il est bien indiqué :
Même en v 3.0 il y a Firefox par défaut, pour Midori il a certes pris de l’embonpoint mais c'est surtout le poids du webkit actuel qui est maintenant plus gros que Firefox
Bon, je retourne à ma traduction d'un plugin Météo pour Lxpanel, il est en bonne voie j'ai recréé/complété le mo fr de lxpanel...
Cordialement,
Médor.
Bien sûr avec une swap ça aide ! Mais en fait Puppy ne décompresse pas tout en ram si elle n'est pas suffisante.
J'ai actuellement avec Slacko-5.7.0 en frugale et 256 Mo de ram dont 12 Mo partagés :
Code: Select all
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 38G 28G 9,4G 75% /initrd/mnt/dev_save
/dev/loop1 124M 66M 59M 53% /initrd/pup_rw
/dev/loop0 157M 157M 0 100% /initrd/pup_ro2
/dev/loop4 140M 140M 0 100% /initrd/pup_ro4
unionfs 124M 66M 59M 53% /
tmpfs 310M 1012K 309M 1% /tmp
shmfs 36M 0 36M 0% /dev/shm
#
Mon fichier de swap affiche : 498/500 Mo, soit 2 Mo d'occupés actuellement.
Et j'ai Opera, Sakura et Leafpad qui tournent en plus de X, Openbox, Lxpanel, Gkrellm
Pour en revenir à Slitaz v3.0, le cd loram fait 132 Mo contre 32 Mo pour l'iso classique...
Voir sur cette page le détail, il est bien indiqué :
(Il n'y a pas de date indiqué, je suppose que c'est pour la v 2.0...).SliTaz-Doc wrote:La taille de RAM minimum pour le noyau SliTaz LiveCD est de 160 MO (128 Mo pour SliTaz 1.0). De nombreuses applications graphiques ne fonctionnent pas avec cette faible quantité de mémoire, il est donc recommandé d'utiliser l'option de démarrage en mode texte : screen = text.
Même en v 3.0 il y a Firefox par défaut, pour Midori il a certes pris de l’embonpoint mais c'est surtout le poids du webkit actuel qui est maintenant plus gros que Firefox
Bon, je retourne à ma traduction d'un plugin Météo pour Lxpanel, il est en bonne voie j'ai recréé/complété le mo fr de lxpanel...
Cordialement,
Médor.
- Attachments
-
- Capture_2014-03-20_174501.jpg
- (58.18 KiB) Downloaded 159 times